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ABSTRACT 

Christopher Alexander has proposed a methodology 
for use in the general process of design. This paper 
investigates the application of this methodology, 
hierarchical decomposition, to the design of computer 
systems. A partial application of hierarchical decompo- 
sition to a real-world computer system, the Navy's Joint 
Uniform Military Pay System (JUMPS), is demonstrated. 

The paper concludes that while hierarchical decomposition 
has direct application to computer systems design, the 
practicality of the application appears limited to systems 
of rather small size. 
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I Introduction 



The rapid progress in all areas of automated data 
processing technology over the past two decades has provided 
the potential for the realization of increasingly sophisti- 
cated and varied applications. The computer-based system 
designer has until recently been relatively successful in 
approaching the problem of design informally and intuitively 
because both the scope and complexity of applications have 
been limited by the technology available for the implementa- 
tion of a design. As this technology has become less 
restrictive, computer applications have grown in size, and 
the design requirements, which define the nature of the 
desired interface between the system and its environment, 
have multiplied rapidly. This growth in design requirements 
has increased the comnlexity of the design process to the 
point where an intuitive, informal approach to problem 
definition no longer suffices. A major constraint to the 
successful implementation of computer application systems 
today appears to be not the underlying technology, but the 
natural limits of the systems designer's intuitive processes. 
At the same time, this problem is aggravated by the limits 
of the language, or verbal concepts, in which design require- 
ments are stated. The further removed from traditional data 
processing new applications become, the less adequate these 
verbal concepts are in aiding the designer in identifying 



and understanding the particular design problems with which 
he is confronted. Some problems can only be partially 
addressed; others may be completely ignored because of the 
lack of a suitable language by which they can be identified 
and included for consideration in the design process. 

Christopher Alexander^ oroposes a methodology for use 
in the general process of designs hierarchical decomposition. 
The methodology allows first for the identification of 
design requirements unencumbered by the traditional languages 
of the designer's disciplines, and, second, for the parti- 
tioning of a set of requirements into subsets sufficiently 
small to allow for seoarate, intuitive evaluation. His 
approach is to treat design requirements as a set of binary 
stochastic variables, some of which are dependent; by 
imposing sufficient conditions on this set, he demonstrates 
that it is possible to decompose the set into subsets so 
that the dependencies between subsets is minimized. His 
proposition is that such subsets of requirements facilitate 
the process of design by defining design problems at a level 
of complexity which can be approached intuitively. 

The hypothesis of this paper is that the approach and 
techniques proposed by Alexander have application to the 
design of computer-based systems. The objective of this 
paper is to evaluate this methodology from the perspective 
of a computer-based system designer. The first chapter 
below discussed Alexander's proposals and methodology. The 
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second chapter proposes some mechanisms by which hierarchi- 
cal decomposition can be applied to computer-based systems 
design. This application is illustrated by considering 
the design problem of a real-world computer-based system, 
the Navy’s Joint Uniform Military Pay System (JUMPS). 
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II Hierarchical Decomposition--An Overview 



The purpose of this chapter is to summarize the metho- 
dology of hierarchical decomposition as presented by 
Alexander, and to define the terminology he employs in its 
exposition. 

a. The design problem . All designers face the same 
problem: that of constrained creation. That is the task 

of design is the invention of purposeful form which meets 
certain requirements imposed by the environment in which 
the form will be employed. These requirements ere generally 
interdependent; an attempt to construct a form to meet one 
requirement may facilitate or make more difficult the 
satisfaction of another. The complexity of a design problem 
depends on both the nvtmber of requirements and their degree 
of interdependence. As the complexity of a design problem 
increases, the innate cognitive ability of the designer 
becomes less capable of integrating the competing require- 
ments he must simultaneously consider. The designer is, of 
necessity, forced to simplify these requirements, to reduce 
them in some way so that he need only consider a mentally 
manageable nxmber at one time. Hierarchical decomposition 
is the methodology proposed by Alexander to achieve this 
simplification, 

Alexander defines form as that part of the world over 
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which the designer has control. The environment, or that 
part of it outside the control of the designer which defines 
the problem (and which is the source of the design require- 
ments) is the context. The form and context together 
compose an ensemble. The context places demands on the 
form, which wo articulate as requirements, or specifications 
which the form must meet to be acceptable. If the form does 
not satisfy a particular demand, misfit is said to occur 
with respect to that demand. The objective of design can 
be restated as the achievement of. fitness between form and 
context. 

b. The destfm -process . Alexander studies in some 
detail the process of design, the process by which the 
designer attempts to construct a form to achieve fitness 
with a given context, Alexander examines two cultural 
archetypes, a selfconscious (advanced, such as our o^m) 
cultural, and an unself conscious (primitive) culture, to 
compare the differences in their approach to design. The 
difference, he contends, is principally in the degree of 
separation between the designer and his form. The unself- 
conscious designer deals directly with form. The self- 
conscious designer is concerned with an abstract represen- 
tation of the form, a picture drawn vfith verbal concepts. 

He is concerned then not directly v/ith the form to be 

designed, but with the "economics” or "acoustics" of the 
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form. These concepts he manipulates by "theories of design" 
espoused by the disciplines of his endeavor, such as archi- 
tecture, in vrhose particular languages these concepts are 
couched. The unselfconscious designer, on the other hand, 
avails himself of no such concepts or theories. Construc- 
tion of form in unselfconscious cultures is most often 
guided by traditions or rituals, which have evolved over 
time as generations of form-makors have adjusted their forms 
in minute ways to correct misfit. As these changes are made, 
if fit results, they are incorporated into tradition: a 
perscription for form-making. This approach is satisfactory 
in unselfconscious cultures because the contexts of their 
forms are stable, or at least change only very slov/ly. The 
unselfconscious designer, then, is seldom faced with a new 
problem, or context, into which his form must be fit. As 
a result, he is not concerned with why certain forms work 
in certain cases, and not in others. He is aware only of 
a right way or a wrong way to construct form, as steeped in 
the tradition and rituals of his craft. 

Alexander suggests that the unselfconscious designer 
often produces more successful forms because his view of 
the design problem at hand is not distorted by the verbal 
disciplinary concepts employed by his self conscious counter- 
part. To remedy this situation in the selfconscious design 
process, the designer must create a further abstraction of 

the problem, a picture which describes only the structure, 
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and excludes the biases of the verbal concepts with which 
the designer normally views the problem, 

\ 

c. Formal representation of the design problem . To 
accomplish this, Alexander proposes the following. Consider 
a point at which the form interacts with the context in any 
way to be a binary variable. If the form designed meets 
the demand placed on it by the context at that point, we 
consider that fit occurs, and misfit otherwise. The collec- 
tion of all such points defines a set of "misfit variables". 
The misfit variables are not all independent, in the sense 
that construction of form to achieve fit at one misfit 
variable may make it easier or harder to achieve fit at 
another. The interdependencies between any two of these 
misfit variables we call "misfit variable interactions". 

Formally, this is represented as an undirected graph 
G(M,L), The set M is the set of misfit variables; the value 
of the variable is 1 if misfit occurs, and 0 otherwise. The 
set L is a set of coefficients describing the interactions 
between the misfit variables; their sign and magnitude 
reflect the direction and strength of the dependency. The 
set M can be viev;ed as the vertices of the graph G, and L 
as the links betwen them, 

G(M,L) is therefore an abstract but formal picture of 

the design problem; it reflects the designer's best estimate 

of the structure of the design problem. In the process of 
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design, the designer attempts to divide this problem into 
subprobleras of smaller scope. The designer would like 
these subproblems to be both as internally cohesive and as 
independent from each other as possible. In terms of G(M,L), 
the subproblems are defined by partitioning M into subsets 
of misfit variables. Because some of the members of M are 
interdependent, as described by the set L, not all decompo- 
sitions of M into subsets are equally beneficial to the 
designer. The most sensible decomposition of M would produce 
subsets of misfit variables which are highly ’’clustered"-- 
in which the density of the links between variables in a 
subset is as high, and the density of links between members 
of different subsets as low, as possible, Alexander provides 
one method of achieving such a “sensible" decomposition of 
the set M, which he calls hierarchical decomposition. 

The algorithm employed by Alexander to achieve this 

is, very generally, as follows. Each misfit variable is 

considered to be a stochastic variable, each chosen so that 

the condition of misfit is equally probable for all variables 

The set L (after suitable normalization) is taken to estimate 

the pairv/ise correlation coefficients between these variables 

Prom these, the probability of any distribution of misfit 

and fit among the elements of M can be calculated. These 

probabilities determine the information content, H(M), of 

the set M, taken as a whole. In a similar fashion, the 

information content of any subset of M, say can be 
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determined by calculating the probability distribution of 
its possible states. 

Consider the partitioning of M into two subsets, 
and S2« The dependence between these two subsets is given 
as R(p), which is equal to H(M)-(H(S^)+H(S2) ) , where p 
identifies the particular partition. V/hat we want to do is 
to select and S2 such that R(p) is minimized (i.£. , such 
that the subsets are as independent as possible). Algorithm- 
ically, an iterative, ”hill-climbing" procedure is employed 
to achieve this. The set M is partitioned arbitrarily, and 
R(p) evaluated. Each misfit variable is then moved, one at 
a time, between and S2 vintil a minimum value for R(p) 
is achieved. The algorithm terminates with the identifica- 
tion of the two most independent subsets of M, The process 
is then repeated by considering each of the subsets in turn 
and decomposing them independently, until the "best" parti- 
tions are single element subsets. The decomposition thus 
takes on the appearance of a binary tree or hierarchy, whose 
nodes at any level represent the best decomposition of the 
immediately proceeding subset. 

d. Solution of the design problem . The designer at 
this point is faced with a number of individual sets of 
misfit variables, each dense in internal interactions, but 

relatively independent of every other such set. They thus 
represent fairly isolated groups of requirements--the 
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designer can consider the nature of the form required to 
avoid misfit in one of the subsets without significantly 
affecting fitness between form and aspects of the context 
defined by other subsets of misfit variables. In this 
hierarchical decomposition, the complexity of the design 
problem has been reduced not by grouping requirements under 
abstract verbal concepts, but by uncovering the structure 
of the context. The solution to the original problem is 
attained by the composition of forms constructed for each 
of the subproblems suggested by the decomposition — the syn- 



thesis of form 



Ill Application of Hierarchical Decomposition to Computer- 
Based Systems Design 

The preceeding chanter provided an overview of 
Alexander's view of the general process of design, the 
process by which forms are constructed, and outlined the 
methodology of hierarchical decomposition. The thesis of 
this paper is that this methodology has a direct application 
to the design of computer-based systems. This chapter dis- 
cusses this application. The first section below examines 
some definitional issues, and the remaining sections investi- 
gate the specific mechanisms by which the methodology of 
hierarchical decomposition can be applied to the design of 
computer-based systems. 

a. Definitions . Before attempting to apply Alexander's 
methodology to computer-based systems design, two definition- 
al issues must be addressed. First, we vtill wish to equate 
’’computer-based system" with Alexander's notion of "form", 
and "computer-based system environment" with "context". To 
do this, we must define, for the purposes of this paper, the 
scope of a computer-based system--which elements or compon- 
ents are part of the form, and which are part of the context. 
Second, we recognize that the "process of design" is not, 
in itself, a single well-defined activity, but is rather a 
concept describing a composition of activities in which the 
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designer participates or undertakes. We must define the 
activities relevant to computer-based systems design in 
which hierarchical decomposition has application, 

(l) Computer-based systems scone . The scope of a 
computer-based system is a central issue in the study 
of computer-based systems design. A computer-based system 
implementation can be viewed as the insertion of an artifi- 
cial form into some larger context. It is the extent of 
the system, the scope of the form being constructed, which 
defines the "systems interface" between form and context. 

p 

As Alexander suggests, 

every design problem begins with an effort to 
achieve fitness between tvro entities: the form 
in question and its context. 

"Fitness" is both a statement of the objective of the design 
process, and a (desirable) condition of the interface 
between form and context. It is essential that the design 
process center, at least initially, on the accurate identi- 
fication of this interface, which Alexander refers to as the 
"form-context boundary". In the first computer-based systems 
application, this boundary was fairly well defined. These 
applications dealt primarily with the automation of manual 
clerical functions, which themselves were well defined. 

Since these traditional data processing applications were 
designed for the replacement of existing forms, usually 

on a one-for-one basis, the form-context boundary could be 
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easily defined. As both technology and experience in 
computer-based systems grew, new systems were developed 
not simply to replace existing (manual) forms, but to inte- 
grate existing functions and to perform functions not pre- 
viously existing. Form-context boundaries became increasingly 
hard to identify. As the "true” interface between a computer- 
based system and its context became more obscurred, the proper 
focus of the design process, the achievement of fitness along 
this interface, was lost. The design process, necessarily 
proceeding from some statement of requirements or function, 
selected system interfaces that could be most easily described. 
This phenomena gave rise to the "narrow” definition of the 
scope of a computer-based system. Many large systems were, 
and continue to be, designed based only on quantitative 
specification of input and output across the most visible 
interface — the computer room door. This strategy, while 
simplifying the design process, ignores the achievement of 
fitness along the broader, and more appropriate, system 
interface. Only after a system thus designed is implemented 
(operationalized), does fit or misfit along this boundary, 
the actual form-context boundary, become apparent. 

For the purposes of this paper, then, we will assume 

a very broad, when compared to the traditional, definition 

of computer-based system. We v/ill assume that not only 

those components within the confines of the computer room 

are included in our definition of form, but also all those 
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necessary to achieve or support the system’s entire fvinction. 
These may include manual or automated correction facilities, 
archival storage and library components, and data transmission 
and receipt facilities. We will also include in our defini- 
tion of form the operating procedures developed for use by 
organizational components of the context v;hich are required 
for system support. 

(2) The design process in computer-based systems . 

Many authors have explored the nature of the design process 
in computer-based systems, and have proposed frameworks to 

3 

describe the activities involved in this process. Murdick 

reviev:s the work of 1? contributors in this area, and 

demonstrates the similarity in approach, if not language, 

in identifying and structuring design-related activities. 

He suggests the following stages for the design process as 

a composite of these separate proposals:^ 

Some problems of nomenclature arise, but an 
examination. .. seems to indicate the following 
synonyms : 

1. Investigation=preliminary survey=problem 
def inition=def ine need or mission objective= 
analyze the present system. 

2. Feasibility s tudy=conceptual design=esta- 
blishment of performance specif ications= 
gross design=Phase I design. 

3. Detailed design=develop system operating 
specif ic at ion s= systems def inition=analysis 
and synthesis=systems acquisition=Phase II 
design. 
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4 • ImpleTTientation-ins tall at ion= systems construction • 

He further points out that^ 

a step-by-step description is not really appropriate. 
Many activities are carried out in parallel* and there 
is much iteration or recycling to refine the design. 

Regardless of the sequence in which these activities are 
actually accomplished, it is suggested that they fall, 
conceptually, into two categories. The first, which we will 
call the "design phase”, encompasses the activities of the 
first three steps in Murdick’s frameviork. The second, or 
"implementation phase”, corresponds to the fourth step. 

The distinction between these two categories is the 
nature of the activities of which they are composed. 

Activities in the design phase can be viewed as processes 
of abstract conceptualization. Beginning with some notion 
of function (s) which the system is expected to perform, 
abstract logical components are assembled to translate some 
input to required output. By contrast, activities in the 
second category, the implementation phase, require construc- 
tion of physical components which display the external 
characteristics of their logical counterparts. 

The distinction between the nature of the activities 
in these tvro categories is underlined by the growing dis- 
parity in formal design aids, or methodologies, available 
for each category of activity. On the implementation side, 
programmers and systems designers have available an increasing 
number of more effective tools to assist them in principal 
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iTTiplementation activities such as code construction and 
hardware selection and configuration. For example, numerous 
algorithms for the performance of standard data' processing 
functions have been developed, cataloged, and analyzed. 
Simulation packages are available to assist in evaluating 
alternatively configured systems’ performance. While the 
implementation phase of the design process has not been re- 
duced (or elevated, depending on point of view) to the realm 
of "science”, there is no question that the computer-based 
systems implementor has a increasing variety of rational 
resources besides his imagination upon which to draw. 

On the design side, however, comparatively little 
progress has been made. Until recently, there were almost 
no tools available to assist the designer in his task of 
developing an integrated logical form which displays fitness 
with its context. Davis observes that^ 

It is one of the anomalies of information systems that 
this field, which is applying technology to informa- 
tion processing at such a rapid rate, has not applied 
technology to any significant degree to its own ana- 
lysis and design process. 

7 3 9 

Recent work by Myers,', Rockart, and King and Cleland have 

begun to provide the systems designer with a model-based 
framework for design and evaluation of computer-based systems. 
Use of these model-based techniques, however, do not as yet 
appear to have achieved widespread practical application. 

As the failure of many computer-based systems develop- 
ment efforts is increasingly attributed to design rather than 
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implementation activities, significant attention has been 
directed toward development of formal design-aiding metho- 
dologies. The most successful of these have found applica- 
tion is the development of detailed design specifications 
and in the initial organization of a computer-based system 
by logical processing modules. These methodologies, including 
"composite design"^® and "structured programming"^^ have 
primary application in the activities of step 3 of Murdick's 
framework. But all of these methodologies proceed from 
explicit statements of general systems requirements and at 
least a basic definition of the proposed system's internal 
architecture--products of Murdick's step 1 and 2 activities. 
While there have been several attempts at providing a formal 
methodology for use in these activities (such as Tiechroew's 
Problem Statement Analyzer ) , these have not achieved any 
practical degree of acceptance. 

In most computer-based systems development efforts, 
designers continue to rely on experince gained through work 
on similar applications. While experience may be the best 
teacher in some endeavors, it is insufficient by itself in 
computer-based systems design for two reasons: 

First, most designers lack an acceptable framework for 

analysis of existing forms. That is, the designer has not 

developed, or been presented with, a robust set of factors 

which explain the viability of a system. Failures and 

successes are explained ^ nost . but these explanations 
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provide the designer little insight from which he can benefit 

in the design of new forms. The best that he can achieve is 

a set of heuristics, specifying necessary design activities 

without explaining the structure of the problem which makes 

these activities advisable. Thus experience in computer- 

based systems design is often ineffective in guiding future 

design due to the lack of a comprehensible framework in which 
to evaluate it. 

Second, the contexts into which computer-based systems 
are inserted vary significantly from application to applica- 
tion, even when the applications (the purpose or function of 
the systems) anpear to be identical. The recent development 
of standard software packages has been made possible only 
through the stringent specification of requirements along 
the "narrow" definition of the form-context boundary. The 
decision to employ such a package and the selection of one 
from amoung those available is an activity of the implemen- 
tation rather than the design ohase, which is more properly 
concerned with fitness along the broader form-context inter- 
face. The process of form design, if it is to be based solely 
on~ experience or tradition (as in Alexander’s unself conscious 
cultures) must necessarily be concerned with a stable, or at 
least only very slowly changing context. The diversity among 
the organizational entities in which computer-based systems 
are employed evidences this lack of stable context in the 
process of their design. 
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VHiat the above suggests is that experience alone is not 
sufficient in coraputer-based systems design. At the same time, 
no design-aiding technologies enjoy popular application. As 
will be suggested below, however, Alexander's raethodoloy of 
hierarchical decomposition has application in assisting the 
designer in these initial design activities (summarized by 
Murdick above as Step 1 and Step 2 activities). 

b. The form-context boundary . The application of 

hierarchical decomposition begins with the division of the 

ensemble into form and context. Alexander defines "form” 

and "context" only in a very general way:^^ 

The form is a part of thw world over which we have 
control, and which vje decide to shape while leaving 
the rest of the world as it is. The context is that 
part of the world vihich puts demands on this form; 
anything in the world that makes demands of the form 
is context. 

The purpose of this section is three-fold; First, to define 
in greater detail the concepts of "form" and "context" by 
examining the nature of the boundary between these from a 
computer-based system perspective; second, to outline an 
approach to selection of the form-context boundary most 
useful to the computer-based systems designer; and third, to 
illustrate this approach through examination of the Joint 
Uniform Military Pay System (JUMPS), 

(l) Nature of the form-context boundary . It is first 
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necessary to recognize that computer-based systems are 
generally implemented in a formal organization environment, 
usually a business or government organization. These organi- 
zations themselves are composed of numerous organizational 
components, usually assembled in a hierarchical fashion, and 
each assigned particular functional responsibilities. In 
accomplishing their assigned function, organizational compon- 
ents seldom act individually, in isolation from each other, 
but rather depend on other organizational components. A 
computer-based system (the form to be designed) whose purpose 
is the displacement of function will interact similarly with 
at least some existing organizational components: It viill 

place demands on some in support of its operation, and will 
have demands placed on it by those components to which it 
provides functional support. 

We will consider these demands as "interactions” between 
the system and identifiable components of the organization 
in which it is implemented, and categorize these interactions 
as follows: 

Information interactions ; Computer-based systems are 
primarily concerned with the processing of information. Many 
functions such systems displace from organizational compon- 
ents are therefore those functions which are likewise infor- 
mation-centered. We will consider those points at which 
information is provided to the system as input, or produced 
by the system as output, to be points of information inter- 
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actions. 



Control interactions : In addition to providing or 

utilizing the information which a computer-based system pro- 
cesses, organizational components may interact with a system 
by controlling its operation in some way, or vice versa. In 
a system designed for the retrieval and display of data, a 
command language, or systems interface, must be provided for 
the user to specify the data to be retrieved or the operations 
to be performed on the data. Other systems may be constructed 
so as to provide output relating to the execution of the 
system, perhaps error messages indicating that certain actions 
must be taken by the operator or user. 

Financial interactions : Some organization components 

interact with the form from a financial perspective. Budget 
offices typically allocate funds or set ceilings on the 
resources available to the prospective system, in terms of 
development, operation, and maintenance. 

Other interactions ? Finally, there are other inter- 
actions which take place between organizational components 
and the form to be designed which are not information, control, 
or financial in nature. These include those interactions which 
specify directly certain requirements which the system must 
meet, and which are common to all systems in a designated 
class. Standard requirements for documentation of a system 
developed within a particular organization is an example of 
such an interaction. Requirements for precautions to be taken 

25 



to insure data base integrity or security of information are 
others. 

We will define the context of the design problem to 
be comprised of all organizational components which will 
interact with the system in one of the ways just mentioned. 

The boundary between the system (form) and these organiza- 
tional components (context) is described by the specific 
interactions themselves. 

(2) Selection of the form-context boxmdary . We can 
consider two separate but related steps in the process of 
selection of the form-context boundary. The first, a 
"general positioning" of the boundary, identifies those 
components outside the control of the designer, but which 
will interact with the form to be designed. The second step, 
"specific positioning", identifies the specific interactions 
between the form and the organizational components of the 
context. 

Three cases need to be considered in general positioning 
of the form-context boundary: 

Displacement of existing function : The simplest computer- 

based system is one which displaces a single function performed 
by an existing organizational component. This organizational 
component itself can be thought of as a foi*ra which the system 
to be designed will, in part, replace. The designer can 
identify those organizational components vrhich interact with 
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this current form through implicit or explicit construction 
of a descriptive model of the functional process. The com- 
ponents thus identified will occupy the context of the design 
problem. 

Displacement and integration of function ; Computer- 
based systems are increasingly implemented to integrate 
functions which may previously have been performed by several 
organizational components. The context of the design problem 
in this case comprises all organizational components which 
interact with the existing forms whose functions the system 
to be designed will displace. These can perhaps best be 
identified, as in the above case, by construction of a descrip- 
tive model of each of the current fxmctional processes. 

Performance of new function : As suggested in the intro- 

duction to this paper, the expanding technological basis for 
computer-based systems has made possible the implementation 
of new function, previously not achievable by existing forms. 
Descriptive models are, of course, ineffective inllocating 
the context of the design problem in this case. Here the 
best the designer can do is anticipate the organizational 
components which will interact with the proposed system: 
those which either will support the system* s operation, or 
which will depend on the system for their own fimctional 
support, 

V7ith regard to the first two cases just mentioned, it 
should be noted that construction of descriptive models of 
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the current functional process(es) which the system will dis- 
place is not, in general, sufficient to identify all compon- 
ents of the context. The system to be implemented may require 
operational support other than that currently available. For 
example, no facility may currently be in place for correction 
of erroneous input to the proposed system. As in the third 
case above, the designer’s task is to anticipate in which 
organizational components these new ” systems support facilities" 
will reside, and use this to augment his descriptive model. 

After the context of the design problem has been generally 
defined, the designer must specifically position the boundary 
between form and context. This is accomplished by identifying 
the specific information, control, financial, and other inter- 
actions between the components of the context and the form 
to be designed. The most salient interactions will be those 
which contribute significantly to stress, or misfit, between 
the existing form(s) and their context(s). The motivation 
for development of the proposed system is often the elimina- 
tion of stress in specific form-context interactions. It is 
important for the designer to realize, however, that all 
interactions must be considered in definition of the form- 
context boundary, not only those interactions currently 
contributing to this stress. The purpose of the form-context 
boundary selection process is to identify an interface between 
the system and its environment along which it is possible for 
points misfit to occur. The designer must include in the 
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form-context boxmdary those interactions which are currently 
satisfactory because he has no guarantee that the form 
suggested by the process of hierarchical decomposition will 
maintain this fitness with those components. The process of 
general and specific form-context boundary positioning is 
illustrated by the following example. 

(3) JUMPS application . To clarify the issues 
involved in the selection of an appropriate form-context 
boundary in computer-based systems design, we will consider 
a real-world system recently implemented within the Navy— 
the Joint Uniform Military Pay System (JUMPS). 

(a) JUMPS overview . JUMPS was originally proposed 

in 1966 as an integrated, automated, centralized replacement 

for the Navy’s manual payroll and leave accounting system. 

The primary objectives of JUtiPS v;ore:^^ 

First, to improve the administration of the Military 
Personnel Appropriations through establishment of a 
central financial reporting system, based on the 
principles of accrual accounting, for the reporting 
of obligations and expenditures from these appropria- 
tions; second, to take advantage of the increased 
availability and effectiveness of automatic data 
processing (ADP) equipment and supporting software 
in the area of military pay. 

While payroll systems are normally considered to be among 
the most simple of computer-based systems to design and 
implement, design and development of JUMPS proved to be both 
lengthy (10 years) and expensive (approximately $70 million). 
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There are several reasons for this, including the sheer size 
of the application (nay accounts are maintained for 600,000 
members), the complexity of the military compensation struc- 
ture (which supports over 100 different types of pay and 
allowances, each with its own particular set of authorizing 
conditions), and the mobility and dispersion of ITavy members 
(who may be assigned to any of more than 1000 units capable 
of world-wide deployment). The most significant reason, 
hoviever, appears in retrospect to have been the designers’ 
lack of appreciation for the true scope of the system which 
they were designing. 

Figure 1 is a general overview of the Navy’s manual 
payroll system as it existed before JUMPS, Navy members 
are assigned to one of some lj.000 commands, or local units. 
Disbursing support for a local unit (or several geographi- 
cally proximate vinits) was provided by a local disbursing 
office. These offices maintained member pay acco\ints 
according to pay procedures issued by the Comptroller of the 
Navy (NAVCOMPT), and based on pay-related transactions and 
member change requests issued by the local unit. Payments 
to members (expenditures) and amovints due members but not 
paid (obligations) were reported by local disbursing offices, 
summarized by NAVCOMPT, and provided to the Chief of Naval 
Personnel (CNP), the Military Personnel, Navy (MPN) Appro- 
priation manager, CNP also received personnel-related trans- 
actions directly from the local unit, from vrhich a data base 

30 




Pre-JTJMPS 
Payroll System 

Fij^re 1 



31 



providing Navy strength and compsition information was 
derived. This information, together with the obligation 
and expenditure reports, assisted CNP in the nrogram, 

I 

planning, and budget execution activities relating to the 
management of the MPN appropriation. Reports of wages and 
of withholding of Federal Income Tax and Social Security 
payments from members’ pay were provided to the Internal 
Revenue Service (IRS) and the Social Security Administration 
(SSA). The Navy Inspector General (IG) was charged with 
conducting periodic formal on-site audits of local disbursing 
office operations. 

This describes briefly the enviornment in which JUIiPS 
was to be imnlemented. JUMPS was expected to perform the 
seven basic functions listed in figure 2 and described more 
fully belov;. 

Pay account maintenance : The official pay account for 

each Navy member viaa to be maintained in automated form at 
the central site (the Navy Finance Center). The local 
disbursing office structure x-jas to be maintained, but their 
function would be limited to transmission of pay-related 
transactions to the central site (also see below under "member 
payments"). These transactions would be initially generated 
by the personnel office of the local unit to which the member 
was attached. These transactions would report any change in 
the member’s status (promotion, unauthorized absence, detach- 
ment, etc.) or the unit’s status (deployed, entered dry dock, 
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Proposed JUMPS Functions and Current 
Responsible Components 



entered combat zone, etc.) which could affect the member’s 

pay account by altering his set of "current entitlements". 

The central site would receive these transactions and attempt 

to update members’ accounts based on the input transaction, 

automated logic (reflecting actual pay procedures then in 

effect), and the current status of the members’ accounts. 

When JUMPS was fully implemented in January 1977# an average 

of 350# 000 transactions were received per month. The major 

difficulty encountered in the design of the system was the 

complexity of the military pay compensation structure. The 

specifications for processing of transactions (implemented 

in the form of decision logic tables) required identification 

and handling of more than 16,000 separate cases. While some 

were trivial, some required almost a complete rewrite of the 

member’s account, with attendant requirements for updating 

history files, audit trails, and tax and expenditure reports. 

In the end, it was decided not to implement some 600 cases in 

l’^ 

the automated update logic but to accomplish the necessary 
action manually in an off-line mode at the central site. 

Member payment ? Payments to members were to be accom- 
plished in one of two ways. First, some members could elect 
to participate in a "Net-check-to-bank" program, under v;hich 
their net pay due (on the l5th and 30th of each month) was 
deposited directly in a financial institution via the 
Treasury’s Composite Check Program^^ Composite checks 
(listing all members and amounts to be deposited at a parti- 
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cular bank) were to be prepared at the central site. Second, 
the member could elect to receive his pay directly, in either 
cash or check. These disbursements were to be made by the 
local disbursing offices, based on pay account status pro- 
vided by the central site (see below under "Account status"). 
The disbursing office would prepare a report of nayments ac- 
tually made for submission to the central site so that member 
pay accounts could be debited. 

Tax reporting : The central site would prepare all reports 

required by the IRS, SSA, and the States, based on the member 
pay accounts. 

Leave account maintenance t JUMPS was also to provide 
a vehicle for leave accoxint maintenance, a function which 
has traditionally resided in the local personnel office. 

Because the military comnensation structure allows a member 
to "sell" unused leave under certain circumstances, and 
because many nay-related transactions also affected a member's 
leave status, an integrated accounting system for both pay 
and leave seemed appropriate. 

Obligation and Expenditure reporting . The central site 
was to prepare monthly reports of obligations and expendi- 
tures to CNP, based on the actual member pay accounts. These 
reports were broken down by numerous categories, and included 
approximately $14.00 million in disbursements each month. 

Personnel account-pay account reconciliation . As men- 
tioned above, CNP maintained an internal data base system, 
the Manpower and Personnel Management Information System 
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(MAPMIS) which provided Navy strength and composition infor- 
mation, and which was maintained by personnel-related trans- 
actions prepared by local personnel offices. Because many of 
the data elements in both JUMPS and MAPMIS were identical, a 
periodic reconciliation between the two systems to insure 
integrity of data was desirable. Although this function had 
not previously been performed, it was not expected to be 
significant, because input to both systems was prepared at 
the same units, the local personnel offices. 

Account Status : The second new function to be perfomed 

by JUMPS was the provision of pay and leave account status to 
the member, the local unit to which he was attached, and to 
the local disbursing office. The statement of account status 
was to include, for each member, all credits and debits, with 
annotations of any changes since the last statement. The 
disbursing office was to use this statement to determine the 
amount of pay due each member paid locally, which was taken 
to be one-half the difference between accumulated credits 
and debits for each bi-monthly payday. The local disbursing 
officer could adjust this amount based on transactions input 
to the central site but not reflected on the current statement 
of account status. 

17 

The general systems specifications developed for JUMPS 

provide for the accomplishment of these functions, and specify 

requirements to achieve these within the systems interface 

outlined in figure 1. As will be discussed belov/, this inter- 
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face embraced only a "narrow" definition of the system’s 
scope, which contributed significantly to the subsequent 
problems encountered in JUMPS development. 

(b) General positioning of the form-context 
boundary . General positioning of the form-context boundary 
requires that the system’s proposed functions be stated, the 
organizational components responsible for these be identified 
(if any), and the organizational components with which these 
currently interact be specified, as . in figure 2. In consider- 
ing "functions", we include those currently residing in a 
single organizational component, those shared among several, 
and new functions not performed by any existing organizational 
component. 

As Figure 2 indicated, JUMPS was both to displace and 
integrate functions performed by several existing components 
and to perform new functions not previously existing. Figure 
3 depicts the actual context of the JUMPS design problem, 
based on those organizational components with which the pro- 
posed system will interact to accomplish its designated func- 
tions. It should be noted that the context of figure 3 does 
not exactly coincide with the JUMPS environment determined 
by the systeufs interface indicated in figure 1. There are 
three major reasons why the assumed system’s interface was 
inappropriate for the JUI4PS design problem, which are visibly 

evident from the differences between figure 1 and figure 3» 
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by JUMPS. By including it within the system, no requirements 
were developed to interface NAPC with the rest of JUMPS. 
Significant problems exist in the operation of the system 
today due to the lack of flexibility within JUMPS to accommo- 
date new interpretations of pay-related legislation. By 
neglecting to consider potential misfit along the NAFC-JUMPS 
interface, significant stress is evident. 

Third, no explicit recognition was given to the inter- 
actions required to support the proposed system function of 
personnel and pay account reconciliation. To accomplish this, 
the CNP data base system, MAPMIS, would need to interact v/ith 
JUMPS to a significant degree. Because MAPMIS vms not identi- 
fied initially as a component of the form-context boundary, 
no requirements were developed to define this interface. This 
problem was belatedly recognized, but only after JUMPS had to 
a large degree been designed. As a result, only limited fit 
between JUMPS and MAPMIS was achievable. 

(c ) Specific positioning of the form-context 
boundary . After the organizational components which directly 
interact with the system have been identified and tentatively 
included as part of the context of the design problem, the 
portions of the boundary relevant to the design problem are 
specified by identifying the specific interactions across the 
boun /. Figure I4. considers a portion of the boundary select- 
ed above by enummerating the possible types of interactions 
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First, the function of leave accoiint maintenance was 
to be displaced from the local personnel office, a component 
of the local unit. By positioning the interface to exclude 
the personnel offices from the “system”, interactions between 
the personnel office and other organizational components 
were ignored in developing systems specifications for JUMPS. 
Specifically, the interaction between the local administrative 
office and the personnel office was not at all considered. 

This interaction, in the form of “pay authorizations", served 
as the basis for preparation of the personnel- and pay- 
related transactions in the personnel offices. As the oper- 
ation of personnel offices was modified to meet JUMPS opera- 
ting requirements, significant misfit between the personnel 
offices and the local administrative offices became evident. 
Because the time frames in which pay-related transactions were 
required to be prepared was not compatible with that in which 
pay authorizations were prepared. As a result, input to JUIIPS 
was significantly less timely than originally expected. Also, 
the control mechanism established for JUMPS input differed 
from that used in the administrative offices, with the result 
that the intended audit trail for input was not effective. 

Second, the Navy Accounting and Finance Center (IIAFC), 

a component of KAVCOMPT responsible for interpreting pay- 

related legislation and regulations and for promulgating 

these to local disbursing offices, was included within the 

system, even though none of its fimction would be displaced 
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by JUMPS. By including it within the system, no requirements 
were developed to interface NAFC with the rest of JUMPS. 
Significant problems exist in the operation of the system 
today due to the lack of flexibility within JUMPS to accommo- 
date new interpretations of pay-related legislation. By 
neglecting to consider potential misfit along the NAPC-JUMPS 
interface, significant stress is evident. 

Third, no explicit recognition was given to the inter- 
actions required to support the proposed system function of 
personnel and pay account reconciliation. To accomplish this, 
the CNP data base system, MAPMIS, would need to Interact viith 
JUMPS to a significant degree. Because MAPMIS v/as not identi- 
fied initially as a component of the form-context boundary, 
no requirements were developed to define this interface. This 
problem was belatedly recognized, but only after JUMPS had to 
a large degree been designed. As a result, only limited fit 
between JUMPS and MAPMIS was achievable. 

(c) Specific positioning of the form-context 
boundary . After the organizational components which directly 
interact with the system have been identified and tentatively 
included as part of the context of the design problem, the 
portions of the botindary relevant to the design problem are 
specified by identifying the specific interactions across the 
boui"5 /. Figure I4. considers a portion of the boundary select- 
ed above by enummerating the possible types of interactions 
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Specific JUMPS Porm-context 
Boundary Positioning 



which can occur, (For simplicity, only information and 
control interactions between JUMPS and the local administra- 
tive office and JUMPS and the member are shown.) Some of 
these interactions currently exist: pay authorizations, 

member change requests, and special pay requests. Several new 
interactions required to support or use the new system’s func- 
tions are also included: request for and provision of account 

status to either the member or the Commanding Officer/admin- 
istrative office, an option to reschedule regular paydays 
by the Commanding Officer (to meet local unit operational 
constraints), and an error notice interaction to allow for 
correction of erroneous input to the system. 

The specifications of form-context interactions (extended 
to include all portions of the form-context boundary) will 
completely position the boundary between the system and its 
context. 

The above JUMPS example serves to illustrate the exten- 
sion of Alexander’s definition of form and context to a 
computer-based systems environment: 

First, those organizational components responsible for 
function which will be displaced by the proposed system must 
conceptually be viewed as part of the form which the system 
will replace, and interactions between them and their "contexts” 
be considered in defining the form-context boundary for the 
new system. 



Second, those organizational components whose function 
will not be displaced by the proposed system must be consider- 
ed as part of the context, so that interactions between these 
and the form to be designed can be determined. 

Third, organizational components with which the proposed 
system will interact in connection with new function must 
be explicitly included in the context to allow for estimation 
of required (but currently non-existant) interactions. 

These considerations will aid the designer in assigning 
the elements of the ensemble (organizational components) to 
form or context in the manner most useful for design of 
computer-based systems. Definition of form and context allows 
the specific interactions between these to be investigated. 
Once these, which define the form-context boxindary, have been 
identified, the designer can proceed to isolate the specific 
points along the boundary at which misfit can occur — the 
process of selection of misfit variables. 

c. Misfit variables . At this point, the designer is 
concerned with developing a set of statements which. reflect 
the possible ways in which misfit might occure bet^^reen form 
and context. This section considers the language, or the 
articulation, of misfit in computer-based systems. 

(l) The nature of “misfit” . We have some general 
notion of ’’misfit*’ as a lack of harmony, or a discordant 
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condition, but a formal definition of the concept is elusive. 
But v/e do know, as discussed above, the conditions under 
which a misfit can occur: at those points of irjteraction 

between form and context. We know, in a computer-based 
systems environment, something of the nature of these inter- 
actions. Form-context interactions, or the demands placed 
on one by the other, occur vjhen information is passed across 
the form-context boundary, when control is exercised, or when 
financial or other requirements must be met. The question 
then becomes one of examining how misfit might occur in 
these four types of interactions. 

(a) Information interaction misfits . We can 
consider two different aspects of the information exchanged 
across the form-context boundary at any given point: its 

content, or subject matter, and its characteristics. The 
characteristics of the information include such qualities as 
accuracy, currency or timeliness, frequency, and level of 

1 s 

aggregation. We could expect misfit to occur if either 
the content or characteristics of the information exchanged 
fail to meet the requirements of the recipient (form or 
context). Moreover, we could expect these requirements to 
vary from context to context, and from point to point along 
a single form-context boundary. This boundary has been pos- 
itioned by identifying those organizational components which 
will interact vrith the form. These components may be differ- 



entiated both by area of activity (marketing, production, 

accounting), and by the level of this activity (strategic, 

tactical, or operational^^). The area of activity will 

generally determine the requirements for information content. 

The characteristics of the information required are largely 

20 

a f\inction of the level of activity. V/ith regard to infor- 
mation interactions between form and context, we therefore 
face possible misfit along a variety of dimensions at any 
given point on the form-context boundary. 

(b) Control interaction misfits . V/hile signi- 
ficant attention has been given to analyzing the informa- 
tional requirements of differing organizational components, 
substantially less has been directed towards understanding 
control interactions in computer-based systems. This is 
understandable in that until recently, the technological 
basis for computer-based systems did not support any signi- 
ficant degree of control interaction between system and user. 
Novi that such facilities as timesharing and on-line data 
base systems are possible, there exists the latitude for 
considerable interaction between system and user which must 
be considered in systems design. Little proposes that there 

exist general requirements which must be met at points of 
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control interaction on the user-system interface. These 
include communicability, ease of control, and robustness. 

These are obviously broad categories of requirements, rather 



than specific statements of potential misfit, but they do 
provide some insight into the nature of misfit in control 
interactions. Stress may occur along a "communicability" 
dimension for a variety of reasons: the language of control 

may be foreign to the context; the mechanism for control 
(lightpen, keyboard) may be too time consuming or too restric- 
tive; error messages or requests for input may be unintelli- 
gible to the context. Similarly, on the "robustness" dim- 
ension, misfit may be evident if the system lacks the ability 
to handle commonly misnelled systems commands. But a key 
point here again is that misfit is a function of both form 
and context, the system and its users. A control language 
perfectly compatible between form and context at one point 
of the interface may result in misfit at another. A data 
base manager, for example, might find that the English- 
like, robust language develoned for the interface between 
the system and the non-technical user to be cumbersome, 
ineffective, or not sufficiently specific for his purposes. 
Little's general requirements, therefore, give some insight 
into the nature of potential misfit in control interactions. 

(c) Financial interaction misfits . Of all 
possible misfits between form and context, those resulting 
from financial interactions are the easiest to understand. 

The most common and most visible misfit evident after imple- 
mentation of a computer-based system has traditionally been 



the misfit between actual accrued development cost and the 
anticipated budget. 

(d) Other interaction misfits . Interactions 
other than those described above have become increasingly 
numerous over time as a growing number of organizational 
components begin to be placed at the form-context boundary. 
This growth is attributable in part to the growing public 
interest in the design and operation of computer-based sys- 
tems. The impact of recent legislation (in the areas of 
privacy and security of information) is just beginning to be 
understood. Specific requirements, in terms of the actual 
design of computer-based systems which would insure fit be- 
tween the system and applicable statutes have certainly not 
been determined. In addition to legislation, there exists 
an increasing tendency for organizations to attempt to stand- 
ardize their computer-based systems and to establish in some 
cases specific regulations for their design. All systems 

for the disbursement of public funds, for example, must 
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comply with General Accounting Office regulations; systems 

developed in the Department of Defense which support military 

operations (such as JUMPS) must include provisions for mobi- 
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lization or deployment contingencies. It is obvious that 
this proli ’ation of requirements provides a fertile field 
for potential misfit. 



With these general ideas of the nature of misfit which 
can occur between a computer-bases system and its environment 
in mind, we will define misfit variable as: A statement of 

a condition relative to interactions between form and context 
which if not met will result in stress, or misfit, in the 
ensemble. 



(2) Traditional approaches to avoiding misfit . It 
may be argued that computer-based systems designers have 
always been concerned with avoiding misfit between the systems 
they design and the context of their application. The tradi- 
tional mechanism employed to this end is a (more or less) 
carefully developed set of specifications, or requirements, 
which the system must meet to be ’’acceptable”. These speci- 
fications are usually formulated based on prospective user 
input and external regulations with which the system must 
comply, Ilie result is a collection of statements, some very 
specific, and some general, upon which the system design is 
based. This collection, for example, will generally include 
edit requirements for input data, algorithms to be used in 
calculating elements of output, specifications of the frequency 
of output and its format, and the budget or resources allocated 
for design, development, and operation of the system. Since 
many successful computer-based systems have been designed and 
implemented on this basis, this traditional approach appears 
to be at least satisfactory for some applications. On the 



other hand, a substantial number of computer-based systems 
have failed to achieve acceptance following the same approach. 
Why does the design process produce successful forms in one 
instance and not in others, when the same basic (traditional) 
methodology is employed, perhaps even by the same designers? 

The process of computer-based systems design is, re- 
calling Alexander's terminology, a *’selfconscious” one. That 
is, the designer is not concerned directly with the particu- 
lar context of the design problem at hand, but rather with 
an abstraction of the context. This is articulated, in the 
traditional approach, through a language which comprises 
those verbal disciplinary concepts peculiar to computer- 
based systems design. As Alexander suggests, use of such a 
language can bias the designer's picture of the design problem. 
Bias is introduced primarily by the ’’preclustering" of points 
of potential misfit into a single verbal concept, such as 
"response time" or "audit trail". In some design problems, 
this preclustering may be appropriate--verbal disciplinary 
concepts may be adequate to describe the structure of the 
context to which the form will be fit. In other, perhaps 
superficially similar design problems, however, the same pre- 
clustering of misfit variables may turn out to be inappropriate 
for independent design choices— a bias has been introduced. 

The following examples from JUMPS illustrate this point. 

(a) JUMPS systems specifications . The basic 



hi 



document providing for the development of JUMPS^^ contains 
more than 150 separate specifications for design of the 
system. Approximately 23 of these can be considered as 
pertinent to the portion of the JTJMPS-context bovmdary des- 
cribed above and depicted in figure i;s the JUMPS-Commanding 
Officer/Administrative Office and the JUMPS-member interfaces. 
Two representative examples of these specifications are:^^ 

When local input to the centralized site is released 
from the local level, unaccompanied by supporting 
documentation, it will be suspended to ensure trans- 
mittal of the required documentation. 

Transactions common to both military pay and personnel 
systems v/ill be input using single source, source data 
automation techniques and will be entered in both 
systems on the same basis, whenever practicable. 

The language of these specifications is clear, as is the 
intent. The first presumable will insure that unsupported 
transactions are not allowed to update internal system’s 
files. The intent of the second is two-fold: to reduce 

clerical workload at the local level, and to achieve compa- 
tibility between the personnel (MAPMIS) and JUMPS data bases. 
The important observation here is that both these specifica- 
tions are included to avoid potential problems, or misfits, 
in the operation of JUMPS, which the designers realized 
through their experience could occur. The language of the 
specifications, while meaningful in the disciplines of data 
processing or computer science, is not specific to the actual 
design problem at hand. The specifications attempt to specify 
how misfit can be avoided without examination of the nature 



of misfit in this particular implementation. 

Considering the first specification, v;e may ask why 
some input might be unsupported. What sort of misfits might 
be created by insisting on such documentation? Is the docu- 
mentation difficult to prepare? Are the timing requirements 
for the input such that supporting documentation cannot be 
prepared in the same time frame? With regard to the second 
specification, we might expect misfit to occur for a variety 
of reasons: Is the organization of the local office such 

that responsibility for preparation of both personnel- and 
pay-related transactions reside with the same person? Can 
local units support or maintain the source data automation 
equipment required? Are the time frames for input to both 
MAPMIS and JUMPS similar? The point here is that while a 
system can be designed to meet these specifications, the 
structure of the actual design problem (the point of potential 
misfit specific to this application) is not apparent from the 
specifications. The specific points of misfit are precluster- 
ed by these design specifications. Even if both of the 
specifications are met, several misfits could result, as 
suggested above. The point is that the structure of the 
design problem has been distorted by employment of tradition- 
al verbal concepts in its description. 

The 23 JUI'^PS specifications pertinent to the portion of 
the JUI4PS-cont6Xt boudary mentioned above are listed in 
Appendix 1, ' 'jse specifications will be used as the basis 

^9 



for the development of misfit variables along the JUl^PS- 
context boundary of figure I 4 .. It will be remembered that 
the selected systems interface for JUMPS (upon which the 
specifications in Appendix 1 were predicated) differs from 
the form-context boundary defined above, and are therefore 
incomplete . 

Traditional systems specification definition may result 

in a successful form if by accident no stress between form 

and context results. What the above JTOIPS example attempts 

to convey is that the language employed in this traditional 

approach to avoiding misfit is too general to provide an 

adequate understanding of the structure of the problem facing 

the designer, the generality due to the implicit ’’precluster- 

ing” of misfit variables. If a system is successfully designed 

following this approach, the designer can take credit only 

for meeting specifications, not necessarily for understanding 

the structure of the actual design problem itself. The 

language of specification and design requirements offer the 

designer an abstract, but biased picture of the problem. What 

we need, suggests Alexander, 

is to make a further abstract picture of our first 
picture of the problem, which eradicates its bias 
and retains only its abstract structural features; 
this second picture may then be examined according 
to precisely defined operations, in a way not 
subject to the bias of language and experience. 

This “further abstract picture” is based on the selection of 

a set of misfit variables appropriate to the context and foma 
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to be designed. The "precisely defined operations" are those 
of a formal decomposition algorithm operating on this set. 

( 3 ) Selection of misfit variables . We have devel- 
oped above the idea of how a computer-based system inter- 
acts with its context and the ways in which these interactions 
might result in a stressful, or misfit, condition between 
form and context. The question facing the designer at this 
point is the articulation of the set of such points of poten- 
tial misfit, the misfit variables. Let us consider the 
qualifications which the statements of misfit variables must 
meet. 



(a) Well-under stood . For a misfit variable to 
be useful to the designer, he must have a clear understanding 
of what conditions must be met to avoid misfit. That is, 
the designer must be able to envision, for any given misfit 
variable, a form which would achieve fit at that point. 

(There are two issues here— estimation of the condition 
necessary to avoid misfit, and a statement of this condition. 
Different designers may have different estimates of the re- 
quired condition. But given that the condition has been 
estimated, the issue here is that the statement of the condi- 
tion must be well-understood.) For some misfit variables, 
the condition required to achieve fit may be stated unambi- 
guously. These are those variables with \-7hich a quantitative 



performance standard can be associated. This will be the 
case for every misfit variable that exhibits continuous 
variation along a well-defined scale. As an example of such 
a misfit variable, we can consider a possible misfit in JUMPS 
associated with the variability in the amounts paid a member 
over several paydays. The designer here recognizes that 
misfit will occur if a member's paycheck varies drastically 
from payday to payday (when no transactions have occurred 
against the member's pay account), (This situation is possi- 
ble in a military pay environment because pay due a member is 
often composed of several items of pay, some of which are 
based on daily rates and others on a standard monthly rate,) 
If the designer can specify the degree of variability allow- 
able without misfit, he can construct a well-understood 
misfit variable. For examples 

Payments to a member cannot vary more than $1,00 
between paydays, excenting variations attributable 
to new transactions against the member's account. 

Here "variability” is dependent on the particular system 

designed, and it exhibits "continuous variation along a well- 

defined scale", namely, a dollar (numerical) scale. The 

variable is a useful one because the condition necessary to 

achieve fit is well-understood--in this case, because a 

performance standard can be specified. 

This is not to suggest that the only allowable misfit 

variables are those with which a performance standard can be 

associated. Some of the most significant misfits (and those 
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most often neglected in traditional systems design) are not 
quantifiable. Consider another example from JUMPS; One of 
the functions of the system is to provide each member with 
the status of his pay and leave account (a Leave and Earnings 
Statement, or LES) , The designer realizes that misfit can 
occur if the LES is not understandable to the member. There 
exists no well-defined scale along which to measure the 
”understandabili ty” of the LES, but this makes the potential 
misfit no less significant. In this case the designer must 
attempt to develop, in a commonsense language, what LET format 
and content are required to avoid misfit. This may be accom- 
plished by demonstration, or by determining some of the 
characteristics the LES need posses to render it understand- 
able; only common abbreviations used, all transactions and 
payments identified by date and type, taxable and non-taxable 
items of pay clearly separated. The point here is that the 
designer must attempt to specify, as completely as possible, 
the conditions to be met to avoid misfit. The fact that for 
a qualitative variable such as this the conditions cannot be 

quantitatively stated does not imply that they cannot be well- 
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understood. In Alexander's words, it is necessary that ' 

each variable be specific enough and clearly enough 
defined, so that actual design can be classified 
unambiguously as fit or misfit. 

(b) Form-independent . It is necessary that misfit 
variables selected be stated in such a way that they do not, 
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a priori , determine the design of the form. As an example 

of a misfit variable which is not form-independent, consider 

a JUMPS design specification for the production of the 

23 

Leave and Earnings Statement: 

The Leave and Earnings Statement will be produced 
solely from data contained in and controlled by 
the pay account maintained by the central site. 

While this statement is v/ell-understood, admission of it as 

a misfit variable may unnecessarily constrain the design. 

If the designer is to have the flexibility in design required 

to maximize fit along the many points of interaction on the 

form-context boundary, the misfit variables he considers 

must be insofar as possible, form-independent. That is, the 

structure of the system to be designed should not be directly 

motivated by the statement of a particular misfit variable. 

In this example, the designer must attempt to restate the 

specification by isolating the misfit it attempts to avoid, 

in a more form-independent manner. One possibility would be: 

The Leave and Earnings Statement should reflect the 
actual status of the member’s pay accoiuit maintained 
at the central site. 

This clearly provides the designer with greater latitude. 

Some information maintained at the local level might be 
included on the LES, or the LES might be produced locally 
based on information provided by the central site. (It may 
turn out, however, that the form suggested by the original 
specification is the one which best satisfies this and 
other misfit variables.) 



Given these qualifications, the designer can begin to 
select misfit variables. The starting point in this process 
is the considerations of the existing form(s) which the 
system will replace (or from which it will displace fiinction) 
Organizational components of the context are studied to iso- 
late both points of misfit and fit with the current form for 
those interactions supporting existing functions which the 
system will assume. The designer will thus proceed around 
the selected form-context boundary, examining all infoxnnation 
control, financial, and other interactions "in place". At 
those points of misfit, the designer must attempt to make a 
specific statement of the misfit variable, one that is both 
well-under stook and form-independent. In information inter- 
action, for example, the designer must isolate the specific 
source of any current apparent stress: Does the misfit arise 

due to content, or is the problem due to incompatabili ty 
between (existing) forta(s) and context along some information 
characteristic dimension (timeliness, accuracy, frequency, 
level of aggregation)? The current points of fit at each 
interaction must also be evaluated, and a statement of poten- 
tial misfit developed. For these existing interactions, 
the performance standard associated with the misfit variables 
is directly available from observation of the performance of 
the existing form(s). 

For those functions which currently exist and will be 
displaced by the system to be implemented, misfit variables 



can be selected based solely on conditions observable at the 
selected form-context boundary. But for new systems func- 
tions or for new systems support functions, the designer has 

no such facility. Alexander's approach in this case is less 
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than precise: 

if we try to design something for an entirely new 
purpose ... the best we can do in stating the problem 
is to anticipate how it might possibly go wrong 
by scanning mentally all the v;ays in which other 
things have gone wrong in the past. 

It can be argued that the major difficulty in computer-based 
systems design is in the specification of systems require- 
ments for performance of new function, and that it is in 
this area that Alexander offers the least insight. We have, 
however, by extending Alexander’s approach to general design 
to the specific design process in computer-based systems, 
provided some focus to his suggested search for potential 
misfit in new functional systems development. In selecting 
the form-context boundary, the designer has identified 
specific organizational components and specific types of 
interactions necessary to support the new function. He is 
aware of the ways in which misfit might occur in these inter- 
actions. In considering a new control interaction, for 
example, the organizational component (in the context) would 
be analyzed to determine the standards the system must meet 
in terms of such variables as robustness and communicability. 
A specific statement of the potential misfit must be made, 
together with the condition required to avoid misfit. In 
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addition to information and control, the designer is aware 
of and considers other interactions which have impact on 
the systems design--the legal or internal requirements the 
system must meet in perfonnance of a new function. 

What Alexander does provide, then, (as extended by the 
considerations developed above) is a framework which focuses 
the designer’s attention on both the locality of potential 
misfit (the form-context boundary), and the types of poten- 
tial misfit (the interactions between the form and context). 

(i;) JUMPS application . To illustrate the general 
approach just outlined, this section developes an initial 
set of misfit variables appropriate to the portion of the 
form-context boundary depicted in figure I 4 . above. Because 
a complete description of this boundary is not available, 
the misfit variables developed below are based on the JUMPS 
systems specifications listed in Appendix 1. As will be 
remembered, these specifications are not exactly aligned 
with the form-context boundary, but v;ere based on the 
systems interface assumed in figure 1 . 

We can first consider the interactions between the 
Commanding Officer/Administrative Office and the manual 
payroll system vjhich support existing functions vihich JUMPS 
will displace. We attempt to state, in as well-understood 

and form-independent manner as possible the conditions necess- 
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ary to avoid misfit in each interaction. 

Pay authorizations : Pay authorizations are the means by 

which member’s pay accounts are adjusted. In their prepara- 
tion, two persons outside the administrative office may be 
involved: the Commanding Officer for certain pay authoriza- 

tion certifications (for those related to specialty or 
proficiency pay), and the member, when required to certify 
contract-related entitlements (such as those which may accrue 
to the member upon reenlistment). V/e include these ’’require- 
ments” as the first two misfit variables: 

1. Commanding Officers should certify certain pay 

authorizations . 

2. Members should certify their elegibility for 

certain pay entitlements. 

Another consideration is that pay authorizations must be 
easy to prepare in the administrative office. We make a 
statement of the potential misfit (but defer the ’’well- 
understood” qualification until later): 

3* Authoriizing documents must be simple to prepare. 

For reasons similar to these, other misfit variables pertinent 
to this interaction between JUMPS and its context can be 
stated: 

i;. Mail service should be employed as the mode of 
input from deployed units. 

5. Pay authorization preparation should not be the 

highest priority work in the administrative 
office . 

6. Administrative office personnel should not be re- 

quired to receive formal training for pay 
authorization preparation. 



7. The vehicle for pay authorizations must easily 

accommodate new or expanded reporting require- 
ments (such as new items of pay). 

8. Facility should be provided for reporting of pay 

authorizations applicable to all members at 
a given unit in a single transaction, when 
such authorizations are based on a change in 
the unit's status. 

9* "Minimize" conditions must be observed in use of 
Naval messages. 

10. Pay authorizations must be input (received by the 

central site) not later than three days after 
their effective date. 

11. JUMPS should not require significant additional 

space in local administrative offices for 
records or equipment used in pay authorization 
preparation. 

12. Sufficient documentation must be retained at the 

administrative office level to allow for audit 
and possible re-input of erroneous transactions. 

13. Pay authorizations must be preparable based only 

on on-board information. 

This first set of misfit variables relates only to the 
information interaction "Pay authorizations". Such an inter 
action exists in the current manual pay system between the 
Commanding Off icer/Administrative office and the personnel 
office, the latter having now been included as part of the 
form to be designed. Although the interaction being consi- 
dered is infonnational in nature, the content of the informa 
tion is not given by the misfit variables developed above. 
Misfits ated to content will be developed during consider 
ation of the JUMPS-NAPC portion of the form-context boundary 
since the NAPC detennines the information required for each 

58 



item of pay and allowance, based on applicable legislation. 
These misfit variables relate generally to the conditions 
which must be satisfied to achieve fit in the operation of 
the administrative office. Some of the variables relate to 
the participants required for preparation of the pay authori- 
zations (1,2,13); others to the modes and timing of the input 
(l|.,9,10); the allowable priority of the v;ork and the capabi- 
lity of the personnel assigned to authorization preparation 
is addressed (3>5>6); the potential for tnisfit if the format 
of the input is not sufficiently flexible to allow changes 
in reporting requirements is covered (7); and other variables 
describe restrictions on space for equipment, documentation 
and forms (11), the need for local audit (12), and ’’unit 
authorization” (8). 

This set of misfit variables represents the first 
attempt at identifying the potential misfit conditions 
relevant to an existing interaction. The next interaction 
considered, also informational in nature, supports a new 
system function--provision of member leave and pay account 
status to the Commanding Officer/administrative office. 

Account status : 

111-. Leave and pay account status must be provided 
at least monthly. 

15. Leave account status should include, by member, 
current leave balance, leave taken, and leave 
lost. 
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16. Pay account status must include, by member, 

pay and allowance items authorized, foreiture 
or checkages of pay, and all one-time entitle- 
ments (such as bonuses). 

I 

17« Information should be provided to verify all 
member receipts/detachments. 

18. Reenlistment eligibility must be provided, by 

member. 

19 . Account status should be easy to interpret. 

The content of the information provided can be directly 
specified here, as can its timing and aggregation, since 
this will not be specified at any other point on the form- 
context bovindary. We consider next the control interactions 
(neither previously existing) between the Commanding Officer/ 
administrative office and JUMPS. 

Payday schedule : 

20. Commanding Officers have the option of re- 

scheduling regular paydays based on oper- 
ational unit schedules. 

21. Rescheduling requests should be directed to 

the disbursing office providing support to 
local unit. 

22. Rescheduling requests should include a unit 

identification and a requested date of 
payment. 

Error notice : 

23 ♦ Erroneous or questionable entitlement authori- 
zations should be returned to the local xmit 
at which correction can be accomplished. 

Request for correction should be specific as to 
the condition for rejection by the central site. 

2 ^, Correction of erroneous input must be accomplished 
within the same time frames as new input. 
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26 , Feedback should be provided to local units 
regarding the accuracy and timeliness of 
authorization preparation. 

Having developed an initial set of misfit variables 
describing the Commanding Officer/administrative office~JUMPS 
interactions, we next consider interactions betvjeen JUMPS 
and the members 

Member chanRe requests : 

27 » Members must have easy access to JUMPS to 
initiate pay account changes (allotments, 
withholding rates), 

28, Members should need to have no formal training 
in military pay procedures. 

Payments : 

29 * Members should be able to specify the mode of 
each payment (either cash or check). 

30, Pay amounts should be predictable. 

31 ♦ The Disbursing Officer under whose symbol pay- 
ments are made should be solely accountable 
for their propriety. 

32, Authorized special payments should be accomplished 
on the day of request. 

33* A member should be able to designate a recipient 
of his pay or portion thereof. 

3I^.. Paydays should be regularly scheduled, 

35 » Members in transit (between duty stations) should 
be able to receive payment of any and all monies 
which may be due them. 

36, A member should not be required to receive all 

pay due him on any payday. 

37. Members should be able to request that their pay 

be deposited directly in a financial institution. 
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Account status: 



38. Members must be provided with the status of 

their pay and leave accounts at least monthly. 

» 

39 . Pay and leave account status must be sufficient 

to predict pay due and leave available for at 
least the month after issue. 

ifO. Account status must be easy to understand. 

i;l. Account status must be identical to that provided 
to the Commanding Officer/administrative office 
(for similar data items). 

42. Distribution of account status to members cannot 

require a significant effort at the local unit. 

Special pay requests ; 

43. Approval of special pay should be the perogative 

of the Commanding Officer. 

44 * Special payments must be limited to monies actually 
earned through date of payment. 

45. Special payments should be normally discouraged. 

These 45 misfit variables represent an initial estimate 
of potential conditions for misfit along a small portion of 
the form-context boundary. The number of misfit variables 
will increase significantly as interactions with other com- 
ponents on the boundary are considered, particularly those on 
the JUMPS-NAPC and JUMPS-MAPMIS portions of the boundary. 

When all portions of the boundary have been considered, the 
process of misfit variable selection ends with a collection 
of well-\mderstood, form-independent statements of potential 
misfit. The collection will be considered the set of misfit 
variables for the design problem at hand. The structure of 
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the problem is in a sense estimated by this set of misfit 
variables, and, as will be seen, by the interdependencies 
among these. 

d. Derivation of a ’’suitable set” of misfit variables . 
Before the dependencies between the selected misfit variables 
are estimated, it may be necessary to modify these to meet 
the restrictions imposed by the formal decomposition algorithm 
to be applied. To support the assumptions and restrictions 
of the algorithm employed by Alexander, the selected set of 
misfit variables must meet three conditions, which is achieved 
by manipulation of the initial set of misfit variables into 
a ’’suitable set”. 

(l) Equal scope . As described above, the algorithm 
for decomposition of the set M (the misfit variables) employed 
be Alexander treats each member of this set as a binary 
stochastic variable. With each variable, there is asso- 

ciated a probability of misfit (P(X^=0)=p^) , It is clear, 
in a real-world context, that achievement of fit is not 

■30 

equally probable for all selected misfit variables. However, 

If we allowed the p^^ to be different for different 
variables Xj^, we should have to bring this into the 
following analysis, \fnich would lead to very com- 
plicated equations, and make it impossible to find 
a simple and general basis for decomposition. 

Therefore we restrict p^ to be equal for all i. What this 

63 



implies is that, of all possible foimis of which the designer 
can conceive, the fraction v;hich achieves fit should be 
roughly equal for each selected misfit variable.* The 
variables, in other words, need to be selected so that they 
are approximately equal in scope. Consider two JUMPS misfit 
variables included in the initial set developed above J 

33 . A member should be able to designate a recipient 
of his pay or a portion thereof. 

37 • Members should be able to request that their pay 

be deposited directly in a financial institution. 

That these variables are not equal in scope can be demonstrated 
by considering the nature of the forms required to achieve 
fit at each misfit variable. Because the first is broader 
in scope than the second, any form resulting in fit with the 
first insures fit with the second: If a member can designate 
(any) recipient of (any) part of his pay, he can certainly 
have his pay deposited at a financial institution. The con- 
verse, however, is not true. To meet this restriction of 
"equal scope", the original misfit variables must be restated: 

33a» A member should be able to allot any (fixed) 
portion of his pay on a continuing basis 
to a designated individual or institution. 

37a» Members should be able to request that the 
balance of unalloted pay due be deposited 
directly in a financial institution on a 
continuing basis. 

Restatement of misfit variables to achieve equality of scope 
is the first step in the manipulation of the initial set of 
misfit variables into a suitable set. 






(2) Partial independence. We will be interested 



in estimating the degree of interaction between selected 
misfit variables. In Alexander’s decomposition algorithm, 
these interaction estimates will be taken (after normaliza- 
tion) to represent the two-variable product moment correla- 
tion between pairs of stochastic variables. The mathematical 
treatment of decomposition requires that this correlation 
be suitably small, ^Vhat this implies to the designer is that^^ 

we must be satisfied that the variables are as 
independent as we can get them to be. 

For example, two of the initial JUMPS misfit variables are: 

30, Pay amounts should be predictable, 

39, Pay and leave account status must be sufficient 
to predict pay due and leave available for at 
least the month after issue. 

As currently stated, the t\^o misfit variables are highly 

dependent, although they were generated to accommodate fit 

along two independent dimensions: to insure against arbitrary 

variability in pay araoxints, and to allow a member to predict 

the amount of pay he is due based on a statement of his 

account status. We might therfore restate the first variable: 

30a, Payments to a member should not vary significantly 
between paydays, excepting variations attribu- 
table to new transactions against the member’s 
account. 

The second step in establishing a suitable set may require 
restatement of the initially selected variables so that they 
are at least partially independent, 
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(3) Specific and detailed . Implied in both the 



above conditions is the notion of specificity of the mis- 
fit variables. The statements of misfit must be* as specific 
as possible for two reasons: First, Alexander's decomposition 

algorithm ignores any third- or higher-order interactions 
between variables. What this implies is that^^ 

the two-variable correlation for any pair of variables 
must be independent of the states of all other variables. 
Since the state of one variable is most likely to affect 
the correlation between other variables, if that one 
variable is wide in scope the best we can do in satisfying 
this is to make all the individual variables as specific 
and minute as possible. 

Second, the broader the statement of misfit, the less removed 

the decomposition will be from the designer's initial 'Verbal 
concept" picture of the problem. The designer must question 

each misfit variable identified to see if a more specific 

statement (or several statements) of misfit can be made. 

Consider the JUMPS misfit variable: 

3, Authorizing documents must be simple to prepare. 

The variable is too general to provide much insight into the 

specific nature of the potential misfit. After further 

investigation into the demands of the context, we could" 

expand this variable to detail more precisely the points of 

potential misfit: 

3a, A common format for all pay authorizations should 
be utilized, 

3b, An error recognized during pay authorization 

preparation should be correctable "in place". 
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3c, Abbreviations and codes used in pay authorization 
preparation should be easily understandable, 

3d, Facility should be provided for one-time entry of 
identical data elements applicable to a series 
of pay authorizations which are prepared at the 
same time, 

3e, Pay authorizations should be event-oriented, 
rather than entitlement-oriented. 

This last misfit variable requires some explanation. In a 

military pay environment, an "event” is defined as a change 

in a member's status: a member reports to a new duty station, 

is promoted, or goes into an unauthorized absence status, for 

example. Several different entitlements (items of pay) may 

be affected by a change in the member's status. The event of 

"a member reports for duty aboard a submarine" will begin 

credit for Sea Duty Pay and Submarine Pay, and terminate 

credit for Subsistence Allowance, In general, the specific 

effects of an event on the set of entitlements due a member 

can only be determined by application of the complicated and 

detailed pay procedures then in effect (as published by the 

Navy Accounting and Finance Center) , By requiring pay 

authorizations to report only events, rather than specific 

changes in entitlements generated by the event, the degree 

of training and expertise required in the administrative offic 

is reduced, and the preparation of pay authorizations is 

simplified. 

The designer's last task in establishing a suitable set 
of misfit variables is to review those variables initially 
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identified and restate these in the most specific and 

0 0 

detailed manner possible. 

The more specific and detailed we make the variables, 
the less constrained G(M,L) will be by previous con- 
ceptions, and the more open to detailed and unbiased 
examination of its casual structure. 



We have begun above to manipulate the initial set of 

JUMPS misfit variables into a suitable set, one which con- 
forms to the constraints imposed by the algorithm to be 

employed for its decomposition. We can proceed in this 

fashion, modifying the initial set to meet the conditions of 

equality of scope, partial independence, and specificity 

required. In addition to the modifications made above, 

the following additional variables are derived: 

19a, Account status provided to administrative offices 
should use only common abbreviations and codes, 

19b, Automatic entitlement changes (pay and allovmnces 
related to longevity) must be clearly indicated, 

19c, Extraordinary account status conditions should 
be highlighted (excess leave, overpaid status), 

19d, A clear indication of the origin of a current 
change in the member's account should be 
provided, 

19e, Summary or trend information regarding the rate 
at which members assigned to a unit use leave 
should be provided, 

27a, Members should not need to be aware of the current 
j;tatus of their accounts to request allotment 
'>r withholding rate changes. 

27b. Members should not be required to use special 
equipment to initiate pay account changes. 
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30a. Payments to a member should not vary significantly 
between paydays, excepting for variations attribu- 
table to new transactions against the members’ 
account. 

i|.0a. Disposition of all amoimts withheld from a member's 
pay must be clearly indicated (taxes, allotments, 
insurance, and other checkages). 

40b. Codes and abbreviations used is describing account 
status should be easily understood or explained 
on the document containing the status. 

i}.0c. Explicit statement of all payments made (both 
locally and centrally) as to date and amount 
must be provided. 

i|.0d. Expiration date of limited entitlements must be 
indicated. 

l 4 - 0 e, ’'Balance brought forward” and ’’balance carried 
forward” amounts must agree on successive 
reports of pay account status. 

The original kB misfit variables have been expanded to 
the 68 now in the suitable set. This example illustrates that 
derivation of a suitable set of misfit variables can require 
significant manipulation of the originally selected variables. 
Moreover, the 68 misfit variables identified here only describe 
a small portion of the JTJMPS-context interface. The JTJMPS-NAPC 
interface, or boundary, will contain a much larger number of 
potential misfit variables, as it is across this portion of 
the form-context boundary that the system's fit with the legal 
requirements for certification and processing of all pay and 
allowance items is specified. While derivation of the complete 
set of misfit variables for the JUMPS application is beyond the 
scope of this paper, some idea of the potential number of these 
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is available from review of the JUl-IPS systems requirements. 

At the JUMPS-NAPC interface alone, approximately 16,000 

34 

seperate processing requirements would need to be considered. 
While this number might be reduced somewhat by careful selec- 
tion of misfit variables, the number of misfit variables in 
the complete set for this design problem is likely to exceed 
20,000. Thus the designer's task in establishing a suitable 
set of misfit variables is likely to be a far more substantial 
undertaking than this abbreviated JUMPS example may indicate. 

e. Misfit variable interactions . The most significant 
distinction betwen Alexander's proposals and traditional 
systems specification definition is the explicit recognition 
by the former of the interrelationships between design 
requirements. It is the articulation of these interralation- 
ships which define the set of links, or misfit variable inter- 
actions that in turn provides stmcture to the design problem 
and enables its subsequent decomposition. This section 
investigates the nature of these links in a computer-based 
systems context and suggests an approach for use in estimating 
the links between bariables in the suitable set, 

( 1) The nature of misfit variable interactions . 

The notion that achievement of fit at one point on the foi^m- 
context boundary may make it easier or more difficult to achieve 
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fit at another is a common one to most designers. In compu- 
ter-based systems, we can consider the concepts of ’‘tradeoff” 
and "concurrence". For example, a common tradeoff facing a 
programmer is between execution time and memory requirement 
for a particular block of code. Prom a slightly broader 
perspective, he may be concerned with the tradeoff betv/een 
efficiency of code and maintainability. A designer may con- 
sider two requirements: one to provide a user with a facility 

for accessing the "current time", and another to develop a 
mechanism to allow for charging of computer usage. The designer 
in this case may see a concurrence between the two requirements, 
in that a form which accomplishes the first (typically through 
a raacroinstruction facility) will make it easier to accomplish 
the second (by basing usage on time and using the same facility 
to determine this). 

The common thread of these examples is that tradeoffs 
and concurrences, or interactions between sources of poten- 
tial misfit, exist because of the structure of the form 
employed. In other words, the designer, through experience, 
realizes that the logical or physical structure of the forms 
he has constructed in the past have been such that tradeoffs 
or concurrences between different requirements have been 
evident. 

Interactions motivated by logical structure : Here the 

designer may consider interactions oossible due to the nature 
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of the logical components chosen to perform a given fxmction. 

The designer may be considering the tradeoff between "ease of 
use” and "flexibility” in a control interaction at some point 
between form and context. A system designed to support the 
first might be implemented as a small set of cammand variables, 
invoked by use of a lightpen on a video display screen. The 
conflict betvjeen this logical implementation and the require- 
ment for flexibility is evident: the user's scope of control 

is limited to a specific set of interactions with the system. 

The conflict, or tradeoff, arises through choice of form. The 
designer is sware of requirement interaction because the logi- 
cal structure of the forms available suggest such an interaction. 

Interactions motivated by physical structure : Consider 

for example a systems implementation on a processor operating 
under a fixed partition, multiprogramming operating system. 

The designer may be considering two requirements: First, 

that an internal automated routine be provided for correction 
of erroneous transactions, and, second, that the system not 
require operator intervention for scheduling. The designer 
may see an interaction (in this case a tradeoff) between these 
two requirements with which the physical implementor (the 
programmer) will be concerned. The degree of automated correc- 
tion achievable will depend in part on the size (in terms of 
memory requirements) of the error correction routines. Operator 
intervention will be required to reallocate partitions if the 
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program size exceeds the largest partition allocated in 
normal operations. A tradeoff is required here, but the 
necessity for it is based on the underlying technology, or 
physical structure, of the form. If the operating system 
employed an alternative memory management scheme (demand 
paging, for example), no operator intervention would be requir- 
ed regardless of the size of the error correction routines. 

In this case, there would be no interaction between these two 
requirements, although other interactions, appropriate to the 
technology of this form, may be evident. 

These examples are insufficient to define formally the 
nature of misfit variable interaction in computer-based systems, 
but they do suggest that such interactions exist, and are arti- 
culated through the designer's experience with the technology 
and logical properties on which these systems are based. In 
Alexander's words. 

We shall say that two variables interact if and only if 
the designer can find some reason (or conceptual model) 
which makes sense to him and tells him why they should 
do so. 

(2) Estimation of misfit variable interactions . 

Having defined a suitable set of misfit variables, and being 
aware of the nature of the potential interactions betv/een its 
members, the designer is in a position to estimate these, to 
establish the set of links L. Hierarchical decomposition allows 
the designer to consider both the direction and magnitude of 
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these links, by assigning a signed weighting to each inter- 
action he sees possible. The strength of interaction can be 
viewed as the potential for concurrence or conflict (tradeoff) 
in achievement of fit for two variables based on the nature of 
the forms available. If the designer considers that the inter- 
action is significant for only a few types of possible form 
designs, he may consider the interaction a weak one. If almost 
every conceivable form results in a conflict or concurrence 
between the two variables, the interaction may be considered 
strong. It is of course theoretically possible to evaluate the 
strenght of interactions far more specifically. Alexander 
suggests, however, that^ 

In practice we shall, at best, be able to distinguish 

two or three strengths of interactions. 

We will consider only two strengths of interaction between 

misfit variables of the suitable set: **weak” and “strong”. 

This distinction is an arbitrary one, but one which intuitively 

may be the easiest to implement. It is also noted that the 

direction of the interactions (conflict or concurrence) need 

not be specified for decomposition by the algorithm employed 
•17 

by Alexander.^ While the reason for this is embedded in the 
mathematics of the decomposition algorithm, the result is 
intuitively appealing, in that we would expect the decomposi- 
tion to depend only on the magnitude of the interaction between 
variables, rather than on the direction of interaction. 
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(3) JUMPS misfit variable interactions . We 
estimate the interactions between the variables in the 
suitable set by considering each variable's potential for 
concurrence or conflict with every other variable. To 
illustrate this, we will consider only the interactions 
between variables in a subset of the JUMPS suitable set of 
misfit variables selected above. This particular subset 
was chosen because the density of the links between variables 
is such that the set is amenable to decomposition. This 
subset will include the variables J 

3a« A common format for all pay authorizations should 
be utilized. 

Pay authorizations should be even-oriented, rather 
than entitlement-oriented. 

4 . Mail service or Naval messages should be employed 
as the mode of input from deployed units. 

6. Administrative office personnel should not be 

required to receive formal training for pay 
authorization preparation. 

7 . The vehicle for pay authorizations must easily 

accommodate new or expanded reporting require- 
ments (such as new items of pay). 

8. Facility should be provided for reporting of pay 

authorizations applicable to all members at a 
given unit in a single transaction, when such 
authorizations are based on a change in the unit’s 
status (such as upon entering a combat zone). 

9. “Minimize” conditions must be observed in use of 

Naval messages. 

13 * Pay authorizations must be preparable based only 
on on-board information. 
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23. Erroneous or questionable entitlement authoriza- 
tions should be directed to the local unit at 
which correction can be accomplished, 

2 i;. Request for correction should be specific as to 
the condition for rejection. 

2 ^. Correction of erroneous input must be accomplished 
within the same time frames as new input. 

We begin by considering potential interactions between 
misfit variable 3 a, the need to employ a common format for 
pay authorization input, and each other variable in the set. 
This is accomplished by construction, if possible, of a 
conceptual model in which avoidance of misfit at variable 3 a 
would make avoidance of misfit at another variable easier or 
more difficult to achieve. Such a model can be constructed 
which "links" variable 3 a with variable I 4 ., the need to utilize 
mail or Naval messages as the mode of input from deployed unit 
motivated by the underlying physical structure of components 
of the design problem. The "link" is based on the fact that 
Naval message transmission equipment can be programmed easily 
to accommodate standard format messages, reducing message 
processing time and message transmission errors. In this 
case, the link between variables is a conctirrence . We esti- 
mate the strength of the link to be strong , since this concur- 
rence is evident in all possible forms, or possible systems 
designs which could be employed. Variable 6 , the need to 
avoid requiring formal training of administrative office 
personnel, co ncurs with variable 3a, This link is based on 



an intuiti' assumption that preparation of input in a single 
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format can be more easily learned than use of multple-f ormatted 
input documents. The strength of this link is again estimated 
to be strong , as this concurrence will be evident in almost 
all possible forms. There is also a weak conflict between 
variable 3a and variable 7, the need for flexibility in the 
vehicle selected for pay authorization input. This conflict 
is evident based on the logical structure of the design problem: 
We reason that use of a single format for input will render 
the future inclusion of new or expanded input requirements 
more difficult. But because there are techniques available 
to achieve fit in both variables simultaneously (perhaps 
through multiple-use, variable length fields on input records), 
this conflict is evident in only some possible forms. The 
link is therefore weak. There appear to be no interactions 
between variable 3a and the other misfit variables in the set. 
Consider for example the potential for interaction betv;een 
variable 3a and variable 13 » the need to prepare pay authori- 
zations based only on on-board information. There seems to 
be no conceptual model, either logically or physically based, 
in which achievement of fit at one variable would make achieve- 
ment of fit at the other either more or less difficult. The 
need for a single format for pay authorization input and the 
need to prepare this input based only on on-board information 
appear to be totally independent, so no link can be established. 
(A point of note here is that this independence is based on 
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the underlying assumption that each personnel/administrative 



office has the same on-board information and will use the 
same single format for input. These assumptions are, in this 
case, valid, but one could easily imagine a situation--a 
design problem — in which these two variables could interact). 
From this point on, we will not consider "non-links", but 
confine the discussion to only those misfit variables which 
can, in the JUMPS design problem, be linked through some 
conceptual model. Variable 3a interactions can be siimmarized 
as: 

3a interacts with I}.(+S), 6(+S), and 7(-W), 

We next consider the potential interactions with the 
second misfit variable in the set: 3©* the need for pay 

authorizations to be event-oriented. The first interaction 
is with variable 6 (no formal training). Based on logical 
considerations, we can reason that, since reporting of events 
(relatively few in number) is easier than interpretation of 
the effect of the event on members* sets of entitlements 
(which are numerous and complex), the two variables concur . 
Since this reasoning would apply to all possible forms, the 
interaction is strong . A weak concurrence between variable 
3e and variable 7 (flexibility in input) is posited: Reporting 

requirements (authorizations) for entitlements are subject to 
change more often than reporting requirements relating to 
events. (This is based on the fact that there exists a 
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relatively fixed number of events --member reports for duty, 
is detached from duty, moves into government quarters, etc. 
Changes in pay procedures in general modify only the ''mapping” 
of events into entitlements. It is therefore possible to 
modify the entitlement structure completely and retain the 
same reporting of events. The event-entitlement "mapping" 
is achieved in an automated fashion at the central site, 
rather than at the local level.) Thus the need to allow for 
modifications in reporting requirements is facilitated by 
employment of even-oriented input. The interaction is weak 
in that future pay procedure changes could include definition 
of new events. We also estimate there to be a strong 
concurrence between varialbe 3© and variable 8, the need to 
provide a facility for pay authorization input based on a 
change in a unit’s status. Because a unit status change is 
interpretted as an event, this condition is most compatible 
with an even-oriented reporting system. Variable 3e also 
concurs with variable 13 » the need to prepare pay authoriza- 
tion input based only on on-board information. Since events 
are well-defined and independent of a member’s set of current 
entitlements and previous status, no reference to a member’s 
account status need be made to prepare input. The interaction 
however, is v/eak is that such information could be made avail- 
able to the local administrative office. Variable 3© interac- 
tions can be summarized as; 
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3e interacts with 6(+S), 7(+W), 8(+S), and 13(+V/), 
Considering next variable I|., the need to utilize mail 
or message input from deployed units, we estimate an inter- 
action betiveen it and variable 9, the need to observe 
’’Minimize” conditions, (’’Minimize” is a condition of radio 
silence employed in vrar time circumstances or in exercises 
designed to simulate these. Varying degrees of '’minimize" 
exist, all of which prohibit the transmission of routine admin- 
istrative "traffic”, which includes pay and personnel related 
messages.) There is an obvious conflict between these variables, 
but its strength is weak , in tlat mail-based input is available 
as an alternative during "minimize". There exists a strong 
conflict , however, between variables ij. and 25» the need to 
accomplish erroneous input turnaround within three days. Mail 
service to deployed units is notoriously poor (except for those 
units with a high degree of air support, such as aircraft 
carriers). Variable li Interactions can then be given as: 

U interacts with 3a(+S), 9(-W), and 25(**S), 

Turning to variable 6 (no formal training), we posit a 
concurrence with variable 8 (facility for reporting unit 
status changes). The conceptual model on v/hich this inter- 
action is founded is based on the structure of the pay pro- 
cedures, Some unit status changes affect entitlements for only 
a portion of the members assigned to a unit. (For example, when 
a ship enters dry dock for a period in excess of 90 days. Sea 
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Duty Pay is terminated for all enlisted members, but officers, 
who are never entitled to Sea Duty Pay, are unaffected.) By 
allowing for a single report of a change in unit ’status, 
administrative office personnel are not required to determine 
which members of the crew underwent an "event", which reduces 
requirement for formal training. The concurrence is weak in 
that a system which allowed for separate input for all members 
assigned could be achieved (v/ith "event applicability" deter- 
mined at the central site). Variable 6 interactions are: 

6 interacts with 3a(+S), 3e(+S), and 7(+W), 

All variable 7 (flexibility in input) interactions have 
already been identified: 

7 interacts with 3a(-W) and 3e(+W), 

Variable 8 (facility for reporting unit status changes) 
interacts with variable 2i|., the need to identify the specific 
condition for input rejection. The model on which this inter- 
action is based is less straightforward than those employed 
above (and in fact may only be evident from the problems 
actually encountered in the operation of JUMPS— a luxury not 
available to the original JU14PS systems designers). A common 
unit status change report is "Squadron S reported for duty 
aboard aircraft carrier on date D", In attempting to "post" 
such a transaction to each member’s account at the central 
site, it may be determined that one member of Squadron S was 

already in a duty status aboard the same aircraft carrier on 
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the date of the "event". The transaction is rejected, but 
the cause of the rejection is not specific. The member may 
have reported early as part of the squadron vanguard and this 
event reported; the member may not have been properly detached 
from previous duty aboard the aircraft carrier; the member 
may have been part of an administrative or logistics unit 
left aboard the carrier between squadron deployments. In 
any case, use of unit status change input complicates the 
error resolution process significantly, and the interaction 
between these two variables is a conflicting one. The inter- 
action is weak , because suitable modification to the "unit 
change" input (such as exception basis reporting) could alle- 
viate this problem. Variable 8 interactions are: 

8 interacts with 4("**S), 6(+V/), and 24(-W). 

Variable 9 ("minimize") interacts with variable 2^ 

(error turnaround requirements), for reasons already stated. 

The interaction is a strong conflict because any system includ- 
ing message-based input is unlikely to meet the error turn- 
around requirements during "minimize" conditions. 

9 interacts with 4(-^'0 and 25 (-S). 

Variable 13 (pay authorization preparation based only on 
on-board information) interactions have already been identified: 

13 interacts with 3e(+W). 

The need to return erroneous input to the local unit at 
which correction can be accomplished, variable 23> con curs 



82 



I 




4 



I 







with variable 2l|. (identify specific reject condition). A 
system which can detect the reason for rejection specifically 
facilitates identification of the local unit at V^hich correc- 
tion can ba accomplished. The interaction is weak , because a 
system could be implemented which returned erroneous input to 
all local units v/hich might possibly be able to correct the 
error. Variable 23 also concurs weakly with variable 25 
(error turnaround requirements), in that this requirement 
will more likely be achieved if the appropriate local unit 
to which the error should be returned can be identified: 

23 interacts with 2ij.(+W) and 25 (+W). 

Finally, variable 2k (identify specific reject condition) 
concurs strongly with variable 25 (error turnaround require- 
ments), for obvious z'easons. 

2k interacts with 8(-W), 23 (+W), and 25 (+S). 

The interactions concerning variable 25 (error turnaround 
requirements) have already been identified: 

25 interacts zijith 4(~S), 9(-S), 23(+W), and 2l|.(+S) . 

A summary of the interactions betv;een variables of this 
subset of JUl-lPS misfit variables is provided in tabular form 
in figure 5* 

Having identified both the elements of the set M, and 
the set of interactions between these, L, a graph of the 
design (sub)problem can be dravm, as in figure 6. The misfit 
variables are identified as nodes of the graph, and the inter- 
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actions as the links between them. Figure 6 provides little 
insight into the structure of the design problem, but by 
redrawing the graph, as in figure 7, two clusters of misfit 
variables become evident. (This simple, first-level decompo- 
sition is accomplished informally, but by inspection it is 
evident that figure 7 represents the best two-way partitioning 
of the subset of JUMPS misfit variables. Application of 
Alexander’s algorithm would yield identical results.) 

Figure 7 therefore suggests that the designer can consi- 
der the two design problems independently, concerned only 
with designing form to achieve fit within each of the separate 
subgroups of misfit variables. It can be argued that this 
decomposition provides the designer with little additional 
insight, in that this particular segmentation of design 
requirements is obvious without the mechanics of misfit var- 
iable selection, interaction estimation and decomposition. 

The reason for this is that the subset of JU>IPS misfit variables 
used in this example reflect only a small number of very 
localized misfit variables. Decomposition of the entire set 
of JUMPS misfit variables may result in variable clusterings 
which are far less intuitive than that indicated by this ex- 
ample. (It is interesting, even in this example, however, 
that the misfit variables regarding the mode of JUMPS input 
(I| and 9) are associated with input error variables rather 

than initial input variables.) This example is not sufficiently 
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broad to demonstrate any significant deviation from the 
"preclustering" suggested by the systems specifications listed 
in Appendix 1. 

One additional and significant point of note is the 
number of misfit variable interactions which the designer 
must consider in deriving the set of links, L, for the decompo- 
sition. This number is given by n(n-l)/2, where n is the 
number of misfit variables in the suitable set. For this 11 
variable JUMPS example, 55 potential links were evaluated, of 
which 15 were considered significant and included in the set 
L. Alexander provides a larger example^"^ which includes li|.l 
misfit variables; 139 i+ links were included in the set L for 
this problem (of a potential total of 987 O). For a vary 
large suitable set of misfit variables, the potential number 
of links which must be evaluated is very high. Based on an 
estimated 20,000 variables in the complete JUMPS suitable set, 
approximately 200 million links would need to be evaluated. 

While a large number of these might be rejected out of hand, 
the actual number of links established and included in the set 
L is still very large. In the above example, the "link density” 
(actual links in L/potential number of links) is 0,27. In 
Alexander's larger example, the link density is O.IL 1 -. These 
two examples alone are insufficient to establish a general 
relationship betv/een link density and the size of the suitable 
set. However, even a link density as low as 0.005 (28 times 
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less dense than in Alexander's example) would result in 
approximately 1 million links in L for the entire JUtIPS 
design problem. Even if only these 1 million links required 
active consideration by a JUMPS designer, and assuming they 
could be each evaluated at the rate of one per minute, the 
total task would require more than 16,000 man-hours. From 
even these rough estimates it is obvious that Alexander's 
methodology for hierarchical decomposition is, at best, 
awkward when applied to very large systems. 
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IV Summary and Conclusions 



This paper has demonstrated a partial application of 
hierarchical decomposition to the design of computer-based 
systems. Figure 8 summarizes the activities involved in the 
application, and their objectives and criteria. Many of the 
benefits to the designer of comnuter-based systems have 
already been discussed. There are two other benefits of 
this methodology, however, which deserve mention. 

First, hierarchical decomposition suoports, rather than 
replaces, the heuristic approaches to design already availa- 
ble. We have seen, for example, that the work of Little 
(regarding important dimensions in form-context control 
interactions) and Gorry and Scott Morton (important dimen- 
sions in information interactions) provide a starting point 
for the identification of misfit variables. It has also 
been suggested that the process of estimating links between 
misfit variables offers the designer a formal vehicle by 
which his experience can be productively brought to bear on 
the design problem at hand. What Alexander's methodology 
represents is not a new and independent approach to design, 
but rather a technique through which both existing heuristics 
and experience can be more formally expressed. As such, it 
can perhaps best be viewed as an effective facilitating 
vehicle for design. 

Second, it was suggested above that the context of a 
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1. 


Functional Specification. 




Objective: 


Identify the functions which 
the system will perform 




Criteria: 


Consider: 

-displacement of existing 
function 

-performance of new function 
-new systems support function 


2. 


General Boundary Positioning. 




Objective: 


Identify organizational compon- 
ents composing the context of 
the design problem 




Criteria: 


Context is formed by those organ- 
izational components outside 
the designer's control v/hich: 
-currently interact v;ith the 
organizational components 
whose function(s) the new 
system will displace 
-will interact with the new 
system either in perform- 
ance of new function or 
for new systems support 


3. 


Specific Boundary Positioning. 




Objective: 


Identify specific interactions 
between form and context 




Criteria: 


Interactions may bet 
-information 
-control 
-financial 
-other 




Hierarchical Decomposition Suraraary 






Figure 8 
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ij.. Misfit Variable Selection 



Objective: Identify points of potential 

misfit in each form-context 
interaction 

Criteria: Misfit variable is a statement 

of a conditions which if not 
met results in stress in the 
ensemble. They must be: 
-well-understood 
-form-independent 



Suitable Set Manimlation . 

Objective: Restatement of selected misfit 

variables to conform to 
requirements of decomposition 
algorithm to be employed 

Criteria: (For Alexander's decomposition 

algorithm) : 

-equal scope 
-partial independence 
-specific and detailed 



6, Misfit Variable Interaction Estimation, 



Objective: Estimation of denendencies 

between all pairs of variables 
in the suitable set 

Criteria: -A pair of misfit variables is 

"linked” by some conceptual 
model available (introspectively ) 
to the designer, based on the 
logical or physical problem 
structure 

-The strength of a link is deter- 
mined by the relative number of 
possible forms in which the 
conceptual model holds 

Hierarchical Decomposition Summary 
Figure 8 (c ontinued) 



7* Decomposition 



Objective: 


Partitioning of the suitable 
set of misfit variables into 
nearly independent subsets, 
each representing a design 
subprobiem 


Criteria: 


Dependent on the decomposition 
algorithm employed 



Hierarchical Decomposition Summary 
Figure 8 (continued) 
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computer-based system, rather than representing a stable 
environment, is subject to considerable change over time. 

It is now also recognized that computer-based systems have 
relatively long lives--that once implemented, they are 
expected to remain in place in an operational status for 
some time. These two observations suggest that a success- 
fully designed form must be easily adaptable to its changing 

39 

environment. As Myers observes, 

we can say that programs never achieve stability. 

They never achieve freedom from bugs or from 

additions or from changes. 

Simon has speculated^^ that successful adaptation, or evolu- 
tion of form is facilitated if it is structured into fairly 
independent subsystems. Such a structure would allow for 
change to take place at a subsystem level, rather than 
require extensive adaptation by the entire form. The objec- 
tive of hierarchical decomposition is the identification of 
nearly independent subsystems in the design problem. In 
a more specific statement applicable to computer-based 
systems, Myers has defined the dimensions along which such 
independence is desirable: independence in informational 

and control interactions between subsystems. Since we 
have based definition of misfit variables in exactly these 
terms, we can expect that the resultant subsystems will be 
as independent as possible along these dimensions. What 
this implies for computer-based systems design is that the 
solution to the design problem has been constructed in such 
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a fashion so as to most readily allow for system maintenance 
(correction of misfits) and expansion (to accommodate change 
in the context). 

While it has been demonstrated that hierarchical 
decomposition can be applied to computer-based systems 
design, it is apparent from the JUMPS example that this 
application may, in some cases, be too lengthy a process to 
be practical. The practicality of the application would 
appear to depend largely on the nature of the computer-based 
system to be designed. We can speculate that large systems, 
in which many specific processing requirements must be consi- 
dered (such as JUMPS), are not amenable to Alexander’s metho- 
dology, based on the sheer number of misfit variables and 
variable interactions which must be defined or estimated. 

In smaller systems, or ones in which such detailed require- 
ments are not imposed, hierarchical decomposition may enjoy 
more practical application. 

In summary, this paper has suggested the potential for 
the application of hierarchical decomposition to computer- 
based systems design; a complete demonstration of this appli- 
cation is, however, still wanting. Many questions and issues 
remain to be explored in this area, principal araoung them 
the characteristics of the design problem necessary for prac- 
tical application of hierarchical decomposition. Efforts to 
answer these questions, could, however, result in the avail- 
ability of a powerful design-aiding methodology for the 
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computer-based systems designer. 



96 



V Notes and References 



Christopher Alexander, Notes on the Synthesis of Form 
(Cambridge: Harvard University Press, 196? ) '« ’ 

^ Ibid .. p. 15 . 

3 

"^Robert G, Murdick, ”MIS Development- Procedures, ” 
Journal of Systems Management . Dec. 1970, pp. 22-26. 

^ Ibid . , p . 2k • 

^ Ibid . 

^Gordon B, Davis, Management Information Systems: 
Conceptual Foundations. S~tructure, and De-velopment c Gr aw- 
Hill, 197)4-)> P. ^+25. 

7 

Glenford J. Myers, Reliable Software Through Composite 
Design (Petrocelli/Charter, 1974). 

0 

John P. Bockart, "Model Based Systems Analysis: A 
Methodology and Case Study," IMR ( Sloan Management Review ). 
Vol. 11, No. 2 (Winter 1970), pp. 1-14 • 

*^V7illiam R. King and David I- Cleland, "The Design of 
Management Information Systems: An Information Analysis 

Approach," Management Science . Vol. 22, No. 3, pp. 236-297. 

^*^Both Myers (7) and W, P, Stevens, al., "Structured 

Design," IBM Systems Journal . Vol. 13 » No. 2 TSpring 1974) » 
pp. 115-139. 

^^0, J* Dahl, et. Structured Programming (London: 

Academic Press, 1972T7 

^^D. Teichroew, "Problem Statement Analysis: Require- 

ments for the Problem Statement Analyzer (PSA)," ISDOS 
V/orking Paper No. 43, Dept, of Industrial Engineering, Univ. 
of Michigan, Ann Arbor, 1971. 

^^Alexander, p. l8, 

^^Requirements and Design for JU14PS in the 1980* s," 
Military Pay Systems Department, Navy Accounting and Finance 
Center, Washington, D.C., 1976, p. 1. 

97 



p. 98 . 

^^Department of the Treasury Transmittal Letter No. 53» 
Sept. 28 , 1970 . 

17 

Department of Defense Instruction No. 7330. Ij., Nov. 

7 , 1966. 

1 s 

See for example G. Anthony Gorry and M. S. Scott 
Morton, "A Framework for Management Information Systems,” 
Sloan Management Review . Vol. XX, No. X (Fall 1971) pp. 55~70, 
or Davis ( 6 ), p. 207. 

19 

Framework proposed by R. N. Anthony, Planning and 
Control Systems: A Framex^ork for Analysis (Boston: Harvard 

University Graduate School of Business Adrainistion, 19^5) 

^^Davis ( 6 ), p. 208 . 

21 

J.D.C. Little, "Models and Managers: The Concept 

of a Decision Calculus," Management Science . Vol. I 6 , No. 8 
(April 1970 ), pp. . 



"Policy and Procedures Manual for Guidance of 
Federal Agencies," General Accounting Office, V/ashington 
D.C,, Titles 2 and 6 . 



^^"Management of Automated Data Systems Development," 
Department of Defense Instruction 5010. 27» July 8 , 1970. 

Department of Defense Instruction 7330.3 (17), 
superseded by Department of Defense Instruction 7330. i+a. 



, 1977. 




^^Ibid., pp 


. 2, 21^. 


26 

Alexander 


(1), p. 77 . 


^"^Ibid., p. 


99. 


^^DoD Instruction 7330. P* 


PQ 

Alexander 


(1), p. 102. 


^°Ibid., p. 


175. 


^^Ibid., p. 
32 

^ Ibid. 


111].. 



98 



^^ Ibid ». p. 115 . 

fact, more than 16,000 separate processing require- 
ments were considered. Documentation for these requirements 
is in the form of decision-logic tables, in the "JUMPS Design 
and Requirements Manual," Navy Finance Center, Cleveland, Ohio, 

1976. 

^^Alexander (1), p. 109. 

^^ Ibid . . p. 111. 

^'^ Ibid . . p. 186 
^^ Ibid .. pp. 136 - 173 . 

^%yers (7), p. 14-. 

Simon, The Sciences of the Artificial (Cambridge: 
MIT Press, I969). 

^^^yers (7), P. 33. 



99 



APPENDICES 



100 



Appendix 1 



The JUMPS misfit variables selected in chapter 3 are 
based on the following systems specifications for JUMPS, 
which were originally contained in Department of Defense 
Instruction 7330 "Requirements for Development, Test, 
Evaluation and Installation of the Joint Uniform Military 
Pay System (JUIIPS)" dated November 7» 1966. The parenthe- 
sized number after each specification refers to the numbering 
of these in the original document. 



1. Individual members of Military Services will 
be paid on regularly scheduled paydays for 
two pay periods each month. The pay periods 
will end as of the l5th and the last day of 
each month. (A.l) 

2. Time between any cut-off of input processing 
for a pay period and date of payment to indi- 
vidual members must be long enough for accurate 
preparation of the payroll, including the appli- 
cation of suitable control procedures and the 
correction and adjustment of errors. (A. 3) 

3. Payroll payments will be made by check unless 
there are obvious benefits in cash payments. 

The "composite check" procedure prescribed in • 
Treasury Transmittal Letter No. 53^ September 
28, 1970, will be applied to the maximum 
extent feasible. (A.L|.) 

I4.. Systems development \-/ill be aimed at reducing 
the manual and clerical workload of operational 
military units and organizations, substituting 
centralized and computerized processing, wherever 
feasible. (A. 10) 
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5. Transactions common to military pay and personnel 
systems will be input using single source, source 
data automation techniques and will be recorded in 
both systems on the same basis, wherever feasible. 
(A.13) 

6 , In addition to periodic, formal Internal audit of 
the operating system, responsible commanders will 
monitor critical input, processing, and output 
points, to assure security and integrity of the 
system, (A.II 4 .) 

?• Accounting for leave earned, leave taken, and 
leave lost v;ill be included in JUMPS, Data 
needed to review and approve individual requests 
for leave will be maintained at appropriate 
operational levels, (3,2) 

8 , For local administration of pay and leave opera- 
tions, a personal financial record will be main- 
tained, It will be used as a temporary file of 
input documents affecting members’ pay, including 
allotment authorizations and will be transferred 
to new duty stations on PCS of the member. 
Reference will be made to this document by 
disbursing officers making payments to transients, 
(II. A. 2) 

9. Individual statements of account will be prepared 
for each member monthly. These statements will be 
called "Leave and Earnings Statements," They 
will be produced solely from data contained in 
and controlled by the pay account maintained by 
the central site, (II. A. If) 

10, The Leave and Earnings Statement will contain, as 

a minimum, the following specific elements of 
information: Here follox^^s a detailed listing 

of these elements of information, including, for 
example, date of preparation, social security 
number, name, all continuing and one-time entitle- 
ments and deductions, (II, A, If, a) 

11. Status changes and actions affecting members’ pay 
accounts may originate at the members’ site and 
enter the pay system via the local finance or 
disbursing officer having custody of the member’s 
personal financial record or may enter the system 
through other systems (e,g., the personnel system). 



102 



In either case, the input v/ill be forwarded to 
the central site in machine-readable form where 
practicable, supported by human-readable docu- 
mentation. Control procedures will be developed 
to ensure receipt by the central site of all data 
transmitted by the originator and the reject and 
suspense of unacceptable data. (II.B.l) 

12. Input procedures and techniques will apply the 
principles of source data automation. Such 
applications may vary due to the nature of the 
input action and environmental conditions, and 
will be flexible, permitting continuing improve- 
ments in such techniques. (II. B. 2) 

13» Where certain special or incentive pay entitlements 
require reports of performance, in a certain time 
frame, or reports of duty at a particular location, 
following initial certification, these reports 
of performance will be on an exception basis (cases 
where entitlement requirements are not met), for 
those personnel normally authorized such payments. 
Authorities responsible for initial certifications 
and recurring exceptions reports will ensure main- 
tenance of adequate and auditable records support- 
ing such certifications and reports. (II. B. 5) 

lli. The system must have a base of accurate, reliable, 
and timely input. Authorities inputting data to 
the military pay system are responsible for the 
propriety and accuracy of such inputs. Pecuniary 
accountability for improper payments will inhere 
in the finance or disbursing officer making pay- 
ments, in accordance with applicable statutes. 

(II. B. 6) 

15» Where source documentation is read directly by EDP 
equipment (by scanning at an intermediate or 
centralized site, for example) it must be forwarded 
as it becomes available, consistent with available 
mail/courier service. In such a situation, copies 
of the documentation will be retained locally in 
the finance or other local office accessible to 
the disbursing officer until receipt of the Leave 
and Earnings Statements from the central site, at 
which time the locally retained documentation may 
be destroyed. (II. B. 8) 
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16, To the extent of local capability, codes, trans- 
actions, status changes, and other input data 
will be pre-edited for validity before communi- 
cation to the central site, (II. B, 9) 

17 , For regular, recurring semi-monthly payments. 
Military Services will pay locally or centrally, 
or by a combination of these methods using 
Treasury check as the payment medium to the 
maximum extent, (II,D,2) 

18 , For members paid locally, the regular pay date may 
be rescheduled, when considered operationally 
desireable by the local commander, (II, D, 3 ) 

19 , Special payments to individual members on a local 
basis, such as partial pay or casual pay, will 

be made as the need arises and will generally 
be limited to emergency or hardship cases and to 
special categories of personnel, such as recruits, 
in-transit personnel or personnel joining or 
being detached from a duty station or activity, 

(II. D, 4 .) 

20, Members will be given the option of having a portion 
of their net pay due carried forward as an linpaid 
item due in their accounts, (II,D,5) 

21, Input to the pay accounts must be complete and 
accurate and adequate controls to assure correct 
processing must be established for accurate and 
complete accounting and reporting. Care v;ill be 
taken to program a complete system of checks said 
balances from input through final output, (II,H) 

22, When input to the centralized site is released 
from the local level, xmaccompanied by supporting 
documentation, it will be suspended to ensure 
transmittal of the required documentation. Such 
suspense file will be a subject for internal 
reviews and audits, (II,H,1) 

23 , Actions rejected by the system will be controlled 
so that appropriate follow-up action can be taken, 
(II.H,3) 
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